Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

From: Brett McDowell <[email-masked]>
Date: Wed, 02 Jun 2010 14:24:46 -0400

On May 28, 2010, at 12:28 AM, Steve Atkins wrote:

> 
> On May 27, 2010, at 9:15 PM, John Levine wrote:
> 
>>> On the other hand, John and Steve expect that the benefits PayPal is
>>> seeing in thwarted phishing messages will be short-lived, as phishers
>>> just change domain names, and send out just as many messages as
>>> before, fooling just as many recipients into thinking they're from
>>> PayPal.
>> 
>> Actually, that's Steve.  John sees utility in manual drop lists, but
>> not in ADSP since there is no way to tell whether someone publishing
>> ADSP understands what it means.  Recent experience suggests that they
>> often don't.
> 
> It's not really my view either. I do think that there's some risk of manual
> drop lists becoming less effective, but I also think that it's more a risk
> than a certainty, and it's something that may be resolved by a couple
> of smart engineers - as it's a flexible approach that can
> be modified in response to opponent behaviour in days or hours.
> 
> That flexibility (and lack of publication of the details) and direct
> involvement of smart people in real time to maintain it are some of the
> things that make the manual drop list approach much more viable
> than a static, self-publication approach.

My problem with this position is that it seems to argue for proprietary one-off solutions vs. Internet standards for email authentication policy assertions.  I would think that's a non-starter, especially for participants in this WG.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 2 Jun 2010 15:26:26 -0400

>> Recent experience suggests that they often don't.
> Can you name someone with ADSP experience who doesn't understand what it means?

Not to pick on you specifically, since there are multiple examples, but 
I'd say that domains that publish dkim=discardable and who let their users 
subscribe and send messages to mailing lists don't understand what their 
ADSP is telling people.

I suppose it's possible they do know and they don't care how much damage 
they cause to everyone else, but I'd rather think it was confusion than 
malice.

R's,
John

---

From: Brett McDowell <[email-masked]>
Date: Wed, 02 Jun 2010 14:29:11 -0400

On May 28, 2010, at 12:15 AM, John Levine wrote:

> ADSP understands what it means.  

ADSP seems to mean one thing to pundits and something else to the people actually using it.  Who is right?

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 2 Jun 2010 15:43:50 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of John R. Levine
> Sent: Wednesday, June 02, 2010 3:26 PM
> To: Brett McDowell
> Cc: DKIM List
> Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong
> Discussion
> 
> > Can you name someone with ADSP experience who doesn't understand
what it
> means?

HA! Something John and I find common ground on. But whereas John's
answer is that people shouldn't use ADSP (A strange position for an
author of ADSP) my answer is that people need to be better educated....
or accept that they run the risk of their endusers mail getting handled
in potentially suboptimal ways. 

It's not that people don't care, it's that this stuff (not just ADSP) is
not particularly easy to understand and implement. Brett is relatively
new to this space and wasn't responsible for the PayPal implementation
but as soon as the maillist/enduser problem was pointed out to him he
started working on addressing it. 

Personally, I'm not feeling quite as adventurous as to implement ADSP
"DISCARDABLE" because it still isn't clear what the breakage rate on
forwarding is. Publishing "ALL" isn't appealing because it leaves
ambiguous what outcome a sender might expect. Do I get the gain for the
pain or do I get nothing or ?

Be that as it may, I'm going to point out again that the MLM issue is
the tail and not the dog. From a BCP perspective it is straightforward
to me:

If the domain or subdomain involved has enduser (at all) accounts then
it is likely a poor candidate for ADSP "DISCARDABLE". ADSP "DISCARDABLE"
should be used for domains that are subject to high levels of abuse and
are used primarily for transactional or marketing email and where the
mail flows are strictly controlled.

Mike

---

From: Brett McDowell <[email-masked]>
Date: Wed, 02 Jun 2010 15:46:19 -0400

On Jun 2, 2010, at 3:26 PM, John R. Levine wrote:

> Not to pick on you specifically, since there are multiple examples, but I'd say that domains that publish dkim=discardable and who let their users subscribe and send messages to mailing lists don't understand what their ADSP is telling people.
> 
> I suppose it's possible they do know and they don't care how much damage they cause to everyone else, but I'd rather think it was confusion than malice.
> 

You'd call it malice to prioritize consumer protection over the a very small population of employees being temporarily inconvenienced by having some of their messages to mail lists delivered to SPAM and in some corner cases, actually unsubscribed from lists... while we invest time and resources to (a) assess how MTA's, MUA's and MLM's actually deal with these mail streams and (b) work with the standards community to improve the ecosystem by shaving off the rough edges we find?

Neither ignorance or malice, simply the will to be an early adopter of young standards with proven consumer protection capabilities coming from a respected source.  Yes, we are learning by doing and we are contributing all of that back to the community.

What surprises me is how our efforts have been received by the community who produced these standards in the first place.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Jun 2010 12:48:23 -0700

> Can you name someone with ADSP experience who doesn't understand what it

Since we've been seeing reports of breakage due to using ADSP records for
domains that are not under sufficient control, it is clear that some fraction of
the ADSP-using world does not understand what it is for, or at least what its
limitations are.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 2 Jun 2010 15:49:23 -0400

> mail flows are strictly controlled.

I entirely agree.  (So there!)

The question remains how to reliably identify such domains.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 2 Jun 2010 15:58:45 -0400

> [email-masked]] On Behalf Of Dave CROCKER
> Sent: Wednesday, June 02, 2010 3:48 PM
> To: Brett McDowell
> Cc: [email-masked]
> > ADSP seems to mean one thing to pundits and something else to the
people
> > actually using it.  Who is right?
> >
what it
> the ADSP-using world does not understand what it is for, or at least
what
> its

If we apply this to other standards (SMTP, DNS, HTTP, etc) we would just
have to power down the whole internet. The best that we can do is come
up with something that makes a modicum of sense, fix things we didn't
anticipate or understand because we needed operational experience and
move on.

There will always be some fraction of the user/implementer base that
won't understand protocols, standards or RFCs. It kind of goes with the
territory.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Jun 2010 13:05:48 -0700

On 6/2/2010 12:58 PM, MH Michael Hammer (5304) wrote:
>> domains that are not under sufficient control, it is clear that some
>> fraction of the ADSP-using world does not understand what it is for, or at
>> least what its limitations are.
>
> have to power down the whole internet. The best that we can do is come up
> with something that makes a modicum of sense, fix things we didn't anticipate
> or understand because we needed operational experience and move on.
>
> There will always be some fraction of the user/implementer base that won't
> understand protocols, standards or RFCs. It kind of goes with the territory.

Mike, this is the sort of discussion disconnect that prevents making progress. 
I'm copying the list because it's a broad-based problem we are all having in 
trying to discuss issues.

First, a question was put forward and I offered an answer.  It is simply not 
fair to then respond in a manner that dismisses that answer (or at least 
dismisses it in this way.)

Second, the usual way that services get successful is to look for problems in 
their use and look for ways to correct them.  Simply saying that there are 
always some problems is not helpful.

Third, we do not have massive amounts of ADSP success which permits 
marginalizing a tiny amount of problems.  We have tiny use, with notable breakage.

Fourth, it has become increasingly clear to me, at least, that there is 
broad-based misunderstanding of what can reasonably be accomplished with DKIM 
and what can reasonably be accomplished with ADSP, versus what cannot.  Failure 
to gain broad-based agreement about both capabilities and limits ensures an 
on-going mismatch in expectations.

If proponents want simply to keep automatically saying that things are great and 
keep automatically rejecting any counter-points, then I'm not clear what the 
purpose of these discussions is.

d/

-- 

   Dave Crocker

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 2 Jun 2010 16:21:16 -0400

> [email-masked]] On Behalf Of Brett McDowell
> Sent: Wednesday, June 02, 2010 3:46 PM
> To: John R. Levine
> Cc: DKIM List

<SNIP>

> 
> What surprises me is how our efforts have been received by the
community
> who produced these standards in the first place.
> 
> 

Brett, I'm sorry you are surprised. 

This space has been contentious going back something like 10 years (or
more). Many of the participants go at it tong and hammer but we can
still sit down for dinner or a drink at the usual gatherings.

Truth be told, the Financial sector (including PayPal) as well as other
key groups have been pretty much MIA from a lot of the discussions for a
long time. Many of the points of contention have been discussed ad
nauseum over the years without resolution or through compromises that
gave us crippled outcomes like ADSP.

Actually, IETF has been somewhat mild compared to MARID <G>.

Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 2 Jun 2010 16:21:59 -0400

> From: MH Michael Hammer (5304)
> Sent: Wednesday, June 02, 2010 4:21 PM
> To: 'Brett McDowell'; John R. Levine
> Cc: DKIM List
> Subject: RE: [ietf-dkim] list vs contributor signatures, was Wrong
> Discussion
> 
> 
> 
> 

Apologies, that should read IETF-DKIM

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Jun 2010 13:25:58 -0700

On 6/2/2010 1:21 PM, MH Michael Hammer (5304) wrote:
> Actually, IETF has been somewhat mild compared to MARID<G>.

Narrower topic.  Smaller group.

Made it a lot easier to be selective with the attacks...

d/

-- 

   Dave Crocker

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 2 Jun 2010 16:36:53 -0400

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Wednesday, June 02, 2010 4:06 PM
> To: MH Michael Hammer (5304)
> >> Since we've been seeing reports of breakage due to using ADSP
records
> for
> >> fraction of the ADSP-using world does not understand what it is
for, or
> at
> up
> won't
> I'm copying the list because it's a broad-based problem we are all
having
> in

Simply stating that we are seeing some reports of breakage due to using
ADSP records for domains that are not under sufficient control does not
add much of anything meaningful to the discussion. This issue has been
discussed for YEARS and now that we see it some people are acting
shocked? I'm shocked I tell you. I seem to remember this very discussion
at an excellent dinner following the FTC workshop in 2007. This same
discussion was held years before that when SSP was just a gleam in
everyone's eye. This is something that was predicted and predictable. 

At the end of the day, ADSP was a compromise that limited usefulness to
a handful of corner cases implemented under extremely tight control at
the risk of breakage and collateral damage if not carefully implemented.

> First, a question was put forward and I offered an answer.  It is
simply
> not
> Second, the usual way that services get successful is to look for
problems
> in

We know the answers for ADSP... see above.

> marginalizing a tiny amount of problems.  We have tiny use, with
notable
> breakage.

I'm still waiting for someone to produce use numbers (of domains) for
ADSP. Just out of curiosity, what number do we have to reach to hit the
technical term "massive"? Somehow I doubt that in it's current
incarnation ADSP will ever have massive implementation.

>From another perspective, in the greater scheme of standards, ADSP is
still very much wet behind the ears. It wasn't until October of 2008
that there was interoperability testing. 

> broad-based misunderstanding of what can reasonably be accomplished
with
> DKIM
> and what can reasonably be accomplished with ADSP, versus what cannot.

I agree with you on that. Something along the lines of pixie dust,
unicorn horns, magic spam prevention, makes you taller and your teeth
whiter... 

> Failure
> to gain broad-based agreement about both capabilities and limits
ensures
> an

And thus the rise of 3rd party "trusted intermediaries".........

> keep automatically rejecting any counter-points, then I'm not clear
what
> the

I'm not a proponent and I'm not saying things are great. I believe I've
stated a few times that I believe that ADSP is crippled and I don't see
myself publishing "discardable". 

When the counterpoints are along the lines of "some people" have "some
problems" and the point is made "if we were following the standard then
we wouldn't be seeing your mail anyways", then my response is..... then
why aren't you discarding it? Either you believe in the standard you
helped craft or you don't.

So, is this a discussion about a BCP for MLMs or is this a discussion
about revisiting the ADSP spec? The course of the discussion really
depends on what the consensus is.

Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 2 Jun 2010 16:40:12 -0400

> Sent: Wednesday, June 02, 2010 4:26 PM

I appreciate that you understood what I meant rather than what I wrote.

> Made it a lot easier to be selective with the attacks...

Actually, I think it was because MARID involved much more of the
characteristics of a religious war. This is merely about passionate
philosophical positions.

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 2 Jun 2010 17:11:24 -0400

> You'd call it malice to prioritize consumer protection over the a very 
> small population of employees being temporarily inconvenienced by having 
> some of their messages to mail lists delivered to SPAM and in some 
> corner cases, actually unsubscribed from lists...

You're welcome to take whatever risks you want with your own mail. 
That's not the issue. I was thinking of the perverse case where another 
organization sent discardable mail to a different list, and unrelated 
people rejected it and got bounced off.  Yes, they both were arguably 
doing something wrong, but it was startling to find second order damage 
from ADSP to someone who wasn't publishing it.

If it's not clear, I think it's wonderful that Paypal signs all their mail 
so that we can reasonably safely dump the unsigned stuff.  I have my mail 
system set up to do that, albeit configured locally, not by ADSP.

The basic problem with ADSP is that we shipped an untested prototype, and 
at this point the only way to test it is to try experiments and hope they 
don't do too much damage before we have a chance to tweak and mitigate the 
problems.  I appreciate that Paypal's intentions are entirely virtuous, 
and that you deal with problems pretty quickly for a large organization.

But since you're the elephant in this particular room, the visibility of 
accidental damage would be particularly great.  I am concerned that since 
the distinction between DKIM and ADSP is unclear to many people, they may 
take away the impression that if they sign with DKIM, their mail will get 
lost.

Since Paypal's practices are for the most part so good, it's very useful 
to be able to talk to people who are scratching their heads about DKIM and 
say "do what Paypal does."  It's harder to say "do what Paypal does, 
except don't do that."

R's,
John

---

From: Brett McDowell <[email-masked]>
Date: Wed, 02 Jun 2010 16:41:46 -0400

> purpose of these discussions is.

If opponents want simply to keep automatically saying that things are terrible and keep automatically rejecting any counter-points, then I'm not clear what the purpose of these discussions is.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 02 Jun 2010 14:43:26 -0700

> and that you deal with problems pretty quickly for a large organization.

This is the list's fault pure and simple. It's subscriber heuristics --
and please do not tell me they are anything but -- failed. While we
shouldn't expect much from mailing list operators and/or developers, we are
most certainly under no obligation to route around their buggy software
as if it were sacrosanct. This is a two way street.

Instead of kvetching about ADSP, you might tell the list owners that their
list software heuristics are broken.

Mike

---

From: Brett McDowell <[email-masked]>
Date: Wed, 02 Jun 2010 16:44:35 -0400

> depends on what the consensus is.

Let's break these up.  Murray tried and I think succeeded to some degree of getting a clear thread that is dedicated only to the MLM BCP.  What makes that a refreshingly productive thread is that we have an I-D to review and comment on.

Perhaps we are at (or long past) the point of diminishing returns in debating the efficacy of ADSP until we have an I-D that covers fixing/enhancing ADSP to make it more useful.

-- Brett

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Jun 2010 14:58:13 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R. Levine
> Sent: Wednesday, June 02, 2010 2:11 PM
> To: Brett McDowell
> Cc: DKIM List
> Subject: Re: [ietf-dkim] the danger of ADSP, was list vs contributor
> 

If we all agree that that's a valid characterization of ADSP, I suggest we move to get it downgraded from Proposed Standard to Experimental.  There's certainly a lot of rhetoric suggesting it's an experiment that's in the process of failing, though the experiment is also arguably not complete.

At any rate, I'm happy to participate in an effort to specify something that actually stands a chance of working, and test it in widely available software.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 2 Jun 2010 15:06:58 -0700

> If we all agree that that's a valid characterization of ADSP, I suggest we move to get it downgraded from Proposed Standard to Experimental.  There's certainly a lot of rhetoric suggesting it's an…

+1

> At any rate, I'm happy to participate in an effort to specify something that actually stands a chance of working, and test it in widely available software.

Also, there have been a couple of suggestions along those lines that at least sound promising, but that weren't based on ADSP. I'm not sure where the best place to discuss them might be (and ASRG isn't it).

Cheers,
  Steve

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Jun 2010 15:08:43 -0700

On 6/2/2010 2:58 PM, Murray S. Kucherawy wrote:
> If we all agree that that's a valid characterization of ADSP, I suggest we
> move to get it downgraded from Proposed Standard to Experimental.

I don't recall seeing anything that looks like "we all agree" on such a point. 
That some do is fine,but  we also know that many do not.

So we all really need to back away from this sort of drama.

 >  There's
> certainly a lot of rhetoric suggesting it's an experiment that's in the
> process of failing, though the experiment is also arguably not complete.

We should all be far more concerned that legitimate questions about limits to 
usability and observed failure scenarios cannot be reasonably discussed.

That's a good way to ensure that serious barriers to widespread successful use 
will not be resolved.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Jun 2010 15:11:47 -0700

> [email-masked]] On Behalf Of Steve Atkins
> Sent: Wednesday, June 02, 2010 3:07 PM
> To: DKIM List
> > At any rate, I'm happy to participate in an effort to specify
> > something that actually stands a chance of working, and test it in
> > widely available software.
> 
> Also, there have been a couple of suggestions along those lines that at
> least sound promising, but that weren't based on ADSP. I'm not sure
> where the best place to discuss them might be (and ASRG isn't it).

A completely new spec with the goal of domain protection tied to DKIM is (theoretically) a good fit for this WG, I would think.

---

From: "John R. Levine" <[email-masked]>
Date: 2 Jun 2010 18:13:28 -0400

> If we all agree that that's a valid characterization of ADSP, I suggest we move to get it downgraded from Proposed Standard to Experimental.  There's certainly a lot of rhetoric suggesting it's an…

At this point, I think a reasonable message is to tell people that it's 
fine to publish whatever ADSP they think best describes their mail stream.

But don't use it to manage your inbound mail unless you're willing to hand 
control of your mail to people of unknown competence and/or virtue.  Some 
senders will be fine, some will not.  I'm trying to come up with as many 
perverse ADSP scenarios as I can.

R's,
John

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 2 Jun 2010 15:54:35 -0600

> subscribe and send messages to mailing lists don't understand what their 

Perhaps another way to put it is that they're not using ADSP discardable in the way that ADSP's designers intended.  This appears to present two options, both of which have been attempted in this thread:

1. assume that the domain owner is wrong
2. assume that the ADSP design is wrong

I think there's also a third option, which I haven't seen explored in depth yet (though I may have missed it):

3. find out why the domain owner thought that their implementation would be okay

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 2 Jun 2010 16:36:10 -0600

> That some do is fine,but  we also know that many do not.

Count me as not agreeing.  We always knew ADSP discardable wasn't appropriate for domains with users who send messages to mailing lists, and is equally inappropriate for all sorts of other legitimate uses of email.  It's possible that the draft doesn't contain a strong enough warning that discardable = mail could be discarded, but that doesn't mean the whole thing is entirely broken.

I'd really like to hear from a domain owner who published a discardable policy even though they knew they had users who send messages to mailing lists.  I'd like to know why they thought it was okay.  Then, we'll know.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 02 Jun 2010 15:47:46 -0700

> list software heuristics are broken.
Michael,

Mailing lists are on higher ground, since they are not introducing the 
new mechanism.  ADSP is dealing with an issue significantly impacting 
less than one percent of email domains.  Mailing lists, on the other 
hand, serve a much higher percentage.

Domains wanting to make restrictive ADSP assertions while using 
third-party services, should enumerate which are to be excluded.  This 
enumeration helps prevent breakage without needing to elicit cooperation 
from non-participants.  This enumeration is possible within a single 
transaction that only occurs with the infrequent corner cases.  The goal 
of reducing the success of phishing is far better met when not requiring 
targeted domains to use more domains or sub-domains as their only means 
to isolate policy.  Especially when this leaves personal interactions 
exposed and creates increased recipient confusion.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Jun 2010 15:56:59 -0700

On 6/2/2010 3:36 PM, J.D. Falk wrote:
>    We always knew ADSP discardable wasn't appropriate
> for domains with users who send messages to mailing lists, and is equally
> inappropriate for all sorts of other legitimate uses of email.

This suggests attempting an exercise.  The exercise is to try to document the 
boundaries for using ADSP.  It requires being careful in describing failure 
scenarios and careful is assessing their likelihood.

As for attempting careful caveats so far, they are scattered around:

    <http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.section.7.3>

Whether they are too generic is a reasonable question to explore.
d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 02 Jun 2010 16:10:52 -0700

On 06/02/2010 03:47 PM, Douglas Otis wrote:
> new mechanism.

When we let existing heuristics dictate what we can design on the net, then we have
failed. Heuristics by their nature are then things that need to deal with their own
shortcomings. The problem here is not with ADSP. It's bad assumptions made by heuristics.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Wed, 2 Jun 2010 16:25:56 -0700

> shortcomings. The problem here is not with ADSP. It's bad assumptions made by heuristics.

The "heuristic" here is that a 5xx ESMTP response means that the
recipient is rejecting email from the sender, I believe. It's not really
an obscure bit of existing practice, rather it's both "best" and "common".

Once we're at the point where we're describing that as something
that can safely be ignored if we want to then I have to wonder
what mail system we're planning to layer all this stuff on top of.

Cheers,
  Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 02 Jun 2010 16:39:46 -0700

> an obscure bit of existing practice, rather it's both "best" and "common".

No. The heuristic is "because I got a reject(s) from this subscriber delivering
his list mail, I'm going to kick him". That's a heuristic. It's not working right.
You could probably get the same bad outcome with a determined attacker not using
ADSP at all.

Mike

---

From: John Levine <[email-masked]>
Date: 2 Jun 2010 23:42:34 -0000

>    <http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.section.7.3>

We put some warnings in RFC 5617, Appendix B, including this one:

B.5.  Domains with Independent Users and Liberal Use Policies

   When a domain has independent users and its usage policy does not
   explicitly restrict them to sending mail only from designated mail
   servers (e.g., many ISP domains and even some corporate domains),
   then it is only appropriate to publish an ADSP record containing
   "unknown".  Publishing either "all" or "discardable" will likely
   result in significant breakage because independent users are likely
   to send mail from the external paths enumerated in Appendix B.1.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Wed, 2 Jun 2010 17:03:12 -0700

>   to send mail from the external paths enumerated in Appendix B.1.

It would be interesting to see the result of someone publishing ADSP
records following the advice in that document. It'd be a good first
step on looking at operational experience.

Cheers,
  Steve

---

From: John Levine <[email-masked]>
Date: 3 Jun 2010 02:34:09 -0000

>> The basic problem with ADSP is that we shipped an untested prototype, ...

The problems with ADSP aren't just for lists, but whatever.

>Instead of kvetching about ADSP, you might tell the list owners that
>their list software heuristics are broken.

Oh, OK, that shouldn't be hard.

I'll get right on it as soon as I'm done telling all the forwarders
to rewrite the envelopes so I can use SPF -all.

R's,
John

---

From: <[email-masked]>
Date: Wed, 2 Jun 2010 18:35:44 -0400

havnt been keeping up with all of the threads so forgive me if I am repeating earlier arguments
ADSP is crippled, intentionally so. Its usefulness is limited to financial transaction types of transactions that may well be easily duplicated with a whale lamp, quill and parchment rbl management.
DKIM is useful to determine who actually sent the mail. 1/2 of SPAM has valid DKIM signatures, the other half (bots) dont use it. It is a decent indicator that is useful along with all of the other tools on the belt. Its not a standalone fixall.
carry on,
Bill

---

From: Michael Thomas <[email-masked]>
Date: Wed, 02 Jun 2010 19:46:54 -0700

> Oh, OK, that shouldn't be hard.

Actually, I doubt it will be hard. The casualties of ADSP causing
third party kicks causes the blame to laid where it deserves: the
list software. I have little doubt that they'll squawk and scream
and throw tantrums about ADSP and in the end fix their broken
software.

Mike, we've already seen the first stages right here, actually
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 3 Jun 2010 04:13:05 -0000

> My problem with this position is that it seems to argue for
> proprietary one-off solutions vs. Internet standards for email
> authentication policy assertions.

That's certainly a reasonable concern.  I expect that if it turns out
there are more discardable domains than Paypal, people would use
shared drop lists, just like they use shared blacklists and whitelists
of IP addresses and domains now.

Last year Paul Hoffman, Arvel Hathcock and I published RFC 5518 on
Vouch by Reference, which we intended as a way to publish whitelists
of responsible domains, originally DKIM signing domains but also
usable for domains that pass SPF -all.  It would only take a small
tweak to VbR to use it to publish shared drop lists.

VbR is deliberately really simple; it's a single DNS lookup, prepend the
name you're looking up to _vouch and the VbR service's name.  The result
is a txt record saying what kind of mail it's vouching for, with the
list currently being all, list, or transaction.

We could add "discardable" as a VbR field, and do lookups like this,
for a list called drop.services.net.

$ dig info.paypal.ca._vouch.drop.services.net txt

; <<>> DiG 9.6.1-P1 <<>> info.paypal.ca._vouch.drop.services.net txt

;; QUESTION SECTION:
;info.paypal.ca._vouch.drop.services.net. IN TXT

;; ANSWER SECTION:
info.paypal.ca._vouch.drop.services.net. 7200 IN TXT "transaction discardable"

(This really works, by the way.  Try it!)

There'd be some other minor tweaks to VbR to bypass an optimization in
VbR that puts hints in the mail about where to look, obviously not
useful if you're looking up mail that you suspect is a phish.

At this point my published drop list contains paypal domains, who
publish ADSP, and ebay and amazon who don't publish ADSP, but who send
transaction mail all of which is as far as I can tell signed.  Looking
at the rest of the signatures in my archive, I don't see anyone other
reasonable candidates yet.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Wed, 02 Jun 2010 21:26:01 -0700

<wakes up>

> incarnation ADSP will ever have massive implementation.

I recently surveyed the domains from which Cisco has received valid DKIM 
signatures:

dkim=unknown: 205 domains
dkim=all: 135 domains
dkim=discardable:  63 domains

There are perhaps some other domains that are publishing 'discardable' 
because they don't send any mail, but we wouldn't have seen them in this 
study.

There's only a weak motivation (involving better DNS caching) for 
publishing dkim=unknown, so it's hard to gauge ADSP deployment by that 
number.  In order to publish all or discardable, the domain's practices 
need to align with that, so unless there's a way to tell that a domain 
is signing all their mail and not publishing ADSP then it's challenging 
to gauge ADSP deployment for either of these categories.

Addressing a question from elsewhere else in this massive thread, my 
home MTA runs the stock version of spamassassin that comes with Fedora 
12.  I haven't tweaked anything.  Assuming my reading of the 
configuration files is correct, spamassassin is querying ADSP for 
incoming mail, and applying a positive bump to the "spamminess" score 
when a message comes from a domain with dkim=all, and a bigger bump for 
dkim=discardable.  This could account for many of the adsp lookups that 
people are seeing.

-Jim

---

From: John Levine <[email-masked]>
Date: 3 Jun 2010 06:25:30 -0000

>dkim=discardable.  This could account for many of the adsp lookups that 

That's mostly right.  In 60_adsp_override_dkim.cf they hotwire fake
ADSP values for about 90 domains, with the discardable ones including
paypal and ebay in many variants, some greeting cards like
americangreetings.com (Hi, Mike) and a few banks.  The "all" ones
include amazon and a fairly randon group probably from mail the
developers got, e.g. astrology.com, linkedin.com,, and
*.greenpeace.org.

They also set lower weights for gmail and yahoo, only if the mail
doesn't look like it came through a mailing list.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 03 Jun 2010 06:01:00 -0700

On 6/2/2010 9:13 PM, John Levine wrote:
> transaction mail all of which is as far as I can tell signed.

What is the pointer to that list?

d/

-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 3 Jun 2010 14:21:59 -0000

>What is the pointer to that list?

It's drop.services.net.  The examples in that message really work.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Thu, 03 Jun 2010 10:03:16 -0700

> The problems with ADSP aren't just for lists, but whatever.
Agreed.

Spamassassin's pre-configured ADSP information represents less than 1% 
of domains being phished, which in turn represent less than 1% of 
domains.  Much like a flea of a flea sitting on an elephant.  While more 
comprehensive lists are possible, publication should be open, the goal 
of ADSP.

The lifespan of phishing domains is often measured in hours, which means 
retaining name recognition and trust represents a reasonable strategy.  
Suggesting use of sub-domains to differentiate policy is 
counter-productive, when it confuses a population that does not 
understand how URIs function, and will not understand that the 
right-hand side of an email-address is changing for policy reasons, and 
that is not a phish.

ADSP, as currently defined, does not offer policy flexibility when using 
a single domain.  In addition, it is not clear whether ADSP is 
recommending receiver handling, or asserting Author Domain policies.  
Rather using reputation as a patch over third-party exceptions, as with 
Vouch-by-Reference, the Author Domain is also able to declare which 
third-party domains are eligible for exceptions in their asserted policy 
of "all" + "3px", for example.  These exceptions might include ancillary 
conditions to narrow their scope.  Unlike Vouch-by-Reference that 
entails subsequent transactions and protocols with different entities, 
the singular ADSP exception transaction is determined by a single protocol.

It is possible to delegate to other services the publication of which 
third-party services require exceptions.  Exception lists might be 
industry related, regional, or community based.  It seems clear the 
third-party authorization draft based upon hash labels should include 
how delegation could be implemented in a manner transparent to recipients.

-Doug