Subject: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict

From: hector <[email-masked]>
Date: Mon, 12 Oct 2009 21:24:56 -0400

The deployment guide section 6.5 writes:

   Any forwarder that modifies messages in ways that will break
   preexisting DKIM signatures SHOULD always sign its forwarded
   messages.

However, there is no implication about forwarder signing restrictions 
in section 6.5 which is possible in section 6.1 regarding ADSP 
support.   Simply put, there is deployment consistent guidelines 
between the two sections:

   - ADSP semantics in section 6.1
   - Forwarder signing semantics in Section 6.5

In order to correct this, I propose the following draft text for 
Section 6.5:

  Before any forwarder attempts to modifies messages and add
  a new signature to the message, it SHOULD look at the
  ADSP record for the 5322.From domain.   If the domain has
  an ADSP record with "dkim=all" or "dkim=discardable", the
  forwards SHOULD NOT forward the message.

     Note: Forwarders who do not support ADSP should be aware
     bounce mail may be result.  For mailing list systems,
     false subscriber removal notifications can occur when
     subscribers MDA receivers are supporting ADSP.

  See section 6.1 for ADSP support recommendations.

Note:

I am not locked in any the words or semantics above. Its just the 
ideal and would be MORE than happy if someone else can better word it 
that could be acceptable by others. My main goal is to highlight the 
inconsistency in the deployment guideline in section 6.1 and section 
6.5 regarding resigners ignorance of ADSP. Since the deployment guide 
is yet to be an RFC, I am under the impression it might be the open 
and the right place to get ADSP and Forwarder semantics.

--
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 13 Oct 2009 10:54:40 +0100

>    preexisting DKIM signatures SHOULD always sign its forwarded

But it should in addition say that it SHOULD also add an  
Authentication-Results header for the signature it is about to break AND  
include that A-R header within what it then signs. That will provide much  
more information to the ultimate recipient.

>   forwards SHOULD NOT forward the message.

No, I think that would lose too much genuinely wanted mail.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: hector <[email-masked]>
Date: Tue, 13 Oct 2009 17:27:52 -0400

> more information to the ultimate recipient.

But what is its not there?    DKIM=DISCARDABLE provides a Domain 
Policy that mail must be signed and valid.

Even if it was there, the transaction could be a 3rd party DSAP violation

> No, I think that would lose too much genuinely wanted mail.

and

   1) create a loophole for spoofs,
   2) create interoperability issues with downlinks,
   3) create false subscriber removal notifications.

Did we forget the Threat Analysis RFC 4886?

   http://tools.ietf.org/html/rfc4686#page-10

   DKIM is effective against the use of specific identities only when
   there is an expectation that such messages will, in fact, be signed.
   The primary means for establishing this is the use of Sender Signing
   Practices (SSP), which will be specified by the IETF DKIM Working
   Group.

Keep in mind that the original SSP included policies that specifically 
dealt with 3rd party signatures inclusion and exclusion:

   - All mail from the entity is signed; unsigned email MUST NOT
     be accepted, but email signed by a third party SHOULD be
     accepted.

   ! All mail from the entity is signed; third-party signatures
     SHOULD NOT be accepted

By ADSP effectively removing the op=- SSP policy, we lost mailing list 
approval controls.

--

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 14 Oct 2009 10:32:32 +0100

> Policy that mail must be signed and valid.

If a valid signature is absent, then indeed the listadmin should discard  
it (maybe even with 'ALL'). But the case of most interest is when the  
message arrives with a valid signature. In that case, the listadmin should  
do his best to forward it, but what does he do if the list policy is to  
munge? That is what we are discussing.

So he adds Authentication-Results and signs it. At least then the final  
recipient can see that and decide to ignore the failure of the original  
signature ("DISCARDABLE" or not), assuming he trusts the listadmin.

But if the final recipient sees that there was NO valid original signature  
(nor any Authentication-Results in that case), then he should of course  
Discard it (even if the original listadmin had not).

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 14 Oct 2009 12:47:46 +0100

--On 14 October 2009 10:32:32 +0100 Charles Lindsey <[email-masked]> 
wrote:

> message arrives with a valid signature. In that case, the listadmin
> should   do his best to forward it, but what does he do if the list
> policy is to   munge? That is what we are discussing.

I think that if you're about to break a signature on a message with 
"DISCARDABLE" policy, then you should reject it (at SMTP time, ideally) 
instead. After all, you're about to render a perfectly good message 
discardable, and that means that it might get lost, and "DISCARDABLE" 
doesn't mean I don't care what happens to any of my mail, it means it can 
be discarded if it carries no valid signature. Actually, if it has a good 
signature, then I can't see why you shouldn't generate a bounce message 
with a good explanation of the reason.

If you're about to break a signature with "ALL", then I agree that you 
should add an authentication-results header, sign it and forward it. The 
recipient can't assess the author reputation now, but can assess yours.

> But if the final recipient sees that there was NO valid original
> signature   (nor any Authentication-Results in that case), then he should
> of course   Discard it (even if the original listadmin had not).

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: hector <[email-masked]>
Date: Wed, 14 Oct 2009 08:31:48 -0400

Charles Lindsey wrote:

>> But what [if] its not there?    DKIM=DISCARDABLE provides a Domain

It was decided in all the documents that have the semantics, and its 
there if you check it,  that the ANCHOR for policy is the 5322.From 
domain.

IOW, we can't use a random AR header that can be forged for this. The 
From: is a traditional header that MUST be there and it represents the 
  traditional constitution for the Authorship and Original Domain.

> Discard it (even if the original listadmin had not).

The issue at hand as a I posted, is whether a intermediary 
(signer/resigner) which technically is also a receiver as well, 
SHOULD|MUST also follows the same rules all receivers is expected to do.

It appears that we want to create semantics for a FINAL RECEIVER, 
probably behaving as a MDA that are not applicable for MTA; relays, 
hops, forwarders, mailing list, middle-ware appliances, etc.

Thats the issue Charles.   We need to get that resolved before we can 
come up with any procedure reading headers, ARs or what have you, to 
classify a message.

Do all Receivers, including intermediary, SHOULD|MUST follow by the 
same rules, specifically in regard to RFC 5617 and ADSP domains?

--

---

From: Steve Atkins <[email-masked]>
Date: Wed, 14 Oct 2009 09:39:42 -0700

On Oct 14, 2009, at 2:32 AM, Charles Lindsey wrote:
> should

The whole point of "discardable" is that the final recipient should not
see it in that case. It's for things like transactional mail, bank  
statements,
that sort of thing - which should never go to mailing lists anyway as
the sender believes it should be sent directly to the final recipient,  
or
not at all.

(If you disagree with my characterization of the sort of email that  
might
use discardable that's fine, but lets be specific about the operational
details, like what classes of email we're talking about. Discussing it
solely in the abstract protects the discussion from common sense.)

A more interesting case to consider is acm.org style forwarders,
where the forwarder is, in many ways, the final destination, and where
the address at the forwarder is "owned" by the final recipient, and
where they will likely ask for transactional mail of the sort that
senders might consider discardable be sent.

Cheers,
  Steve

---

From: hector <[email-masked]>
Date: Wed, 14 Oct 2009 13:17:41 -0400

Lets please keep the focus:

Section 6.1 and 7.4.1 describe a ADSP standard.

Section 6.5 describes a forwarding signing semantics that conflicts 
with 6.1 and 7.4.1.

This is not a matter of one spec predating another. The deployment 
guide attempt to merge the suite of DKIM technologies.

Under IETF protocol design methodology for sound engineering 
integration, these sections needs to be codified and corrected to 
assure we do not create network adoption interoperability problems.

--

---

From: John Levine <[email-masked]>
Date: 14 Oct 2009 17:23:16 -0000

>senders might consider discardable be sent.

Our working hypothesis has been that most forwarders of that sort won't
break the signature, so it's not a problem.

The flame wars erupt when you ask who, if anyone, should sign mail from
domains like acm.org that are sent from a thousand random networks around
the world where ACM members happen to get their mail.

R's,
[email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 14 Oct 2009 10:39:04 -0700

> break the signature, so it's not a problem.

FWIW, this highlights the difference between an "Alias" and most other 
Mediators, a la RFC 5598.  An Alias modifies a portion of the message -- SMTP 
RCPT-TO -- that is not covered by a DKIM signature.  Hence it does not break it.

This of course does not mean that an Alias Mediator should not (also) add a DKIM 
signature.

d/

-- 

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

---

From: Daniel Black <[email-masked]>
Date: Thu, 15 Oct 2009 19:51:04 +1100

> more information to the ultimate recipient.
This is good.

> No, I think that would lose too much genuinely wanted mail.

I'm not convinced there would be much genuinely wanted email in this case.

I believe there are sufficient mailing lists out there that break DKIM 
signatures sufficient for the DKIM WG to consider them fully the DKIM 
standardization suite.

My quick assertion is:

"The input to these mailing lists is, in every sane case that I can think of, 
direct from the author."

THE INSANE CHAIN of MAIL LISTS

The insane case I can recall is (with names anonymised):

A group of server administrators of a software mirror site maintained a 
mailman list with all their email addresses as a subscribers. They got 
convinced to mirror a linux distribution on their mirror. This linux distro 
had another email list for communicating amongst mirror admins. Our group of 
server admins subscribed their mailing list address to the mailing list for 
mirror admins. The impact of this was a mirror admin would email to the mirror 
admin list. This would distribute an email to our group of server admins via 
their list. Our server admin list would reject the email back to the mirror 
list saying "please confirm email" and this email was sent to every mirror 
admin. The end result was our group of server admins was force-ably 
unsubscribed from the mirror list and told to subscribe sensibly (sanely).

What has this got to do with DKIM? well it highlights that chaining email 
lists that require subscribers or email confirmation won't work because they 
don't share common subscribers. These are the kind of email lists that break 
DKIM signatures. The current in-operability of chained email lists make this 
already a rare (and insane) configuration.

The world of spam was made the "require subscribers or email confirmation" a 
common type of DKIM signature breaking email list.

Had the server admin list been a simple alias expander then there would of 
been no problem. As Dave has already said further down this thread, alias 
expanders aren't a problem with DKIM and the same applies here.

PLEA:

if ANYONE has a reason why a email forwarder that breaks DKIM signatures would 
receive a broken DKIM signature in a fairly common case please share this now!

ALTERNATE:

If there are cases here, or perhaps if we just want to be more liberal, then 
perhaps email forwarders need to see if there is any Third Party 
authorizations from the Author Domain delegating authority to a third party to 
sign on their behalf (don't look at Doug's draft yet - an updated one will be 
coming out soon).

SUPPORT +1

Short of a quantification from the words above if needed, I'm totally in 
support of Hector's proposal to reduce the conflict in the deployment guide, 
and encourage forwarders that break signatures to consider the Author Domain's 
wishes up front (in not forwarding broken signatures when 
ADSP=ALL/DISCARDABLE), as they are unlikely to receive a valid message with a 
broken signature.

Daniel

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 15 Oct 2009 12:02:59 +0100

>   traditional constitution for the Authorship and Original Domain.

The reliability, or forgeabbility of what I am proposing is a matter we  
can indeed discuss. But I would claim it is at least better than doing  
nothing about this issue.
>> signature

There is no SHOULD|MUST about what recipients do. At most, it is a matter  
of Best Common Practice, which this WG might well choose to incorporate in  
a BCP RFC. But what would such a BCP document say?

It might say that all invalid DISCARDABLE email "SHOULD" be discarded.

It might say that all invalid DISCARDABLE email "SHOULD" be marked as such  
and sent on.

It might say that invalid DISCARDABLE email "SHOULD" be treated in some  
different way if accompanied by a signed A-R record as I have suggested.

It might say that Listadmins "SHOULD" treat mail addressed to their list  
just like any other recipient "SHOULD" treat it.

It might say that Listadmins "SHOULD", as a special case, take actions  
different from other recipients (whether by adding A-R records, or  
something else).

It might (or might not) make special recommendations for other forwarders,  
such as acm.org.

None of these possibilities is, a priori, preordained. None of them is  
contrary to anything currently on the Standards Track.

All of them are a proper subject of discussion, should this WG decide to  
embark on such a BCP (and the misunderstandings repeatedly displayed here  
seem to suggest that something of the sort is needed).

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 15 Oct 2009 14:02:35 -0600

> seem to suggest that something of the sort is needed).

Agreed, except for one thing: until there's a larger set of users of ADSP, 
no practice can be said to be common.

A "considerations for use" document might help, though I'm not sure what it 
could say that the RFC doesn't already cover.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Thu, 15 Oct 2009 13:13:18 -0700

> could say that the RFC doesn't already cover.

Better would be what not to do/expect, and I think that the RFC is sort of
skimpy on that point.

That said, I doubt we could ever come to consensus.

Mike

---

From: hector <[email-masked]>
Date: Thu, 15 Oct 2009 17:01:30 -0400

> could say that the RFC doesn't already cover.

The issue is about codifying the existing but conflictive semantics to 
prevent problems and maybe even help to lay the ground for wider 
adoption across the board.

One part says "THAT is possible."   Another part says "THIS is 
possible."  Whats missing in THIS is: "Oh by the way,  if you do THIS, 
you need to maybe check THAT because THIS will break THAT and THAT 
will break THIS."

That is all I am noting here and IMO, the "correction" will allow for 
wider consideration and new implementations to at least be consistent 
and please note, I am speaking of only about intermediaries.

If that was agreed and added, at lease from this small lonely 
developer perspective, I will be comfortable, enabled our compiler 
directives "#define SUPPORT_DKIM", recompile and instantly offer 
DKIM/ADSP support in our next updates. At least few thousand operators 
will instantly have the feature offerings.  I will be comfortable 
because when an ADSP standard violation happens by some other system, 
we can then pass the buck and throw the book at them. :)

--

---

From: hector <[email-masked]>
Date: Thu, 15 Oct 2009 19:27:57 -0400

> a BCP RFC. But what would such a BCP document say?

I agree, but at some point implementators will need to transform the 
functional specification into a technical one.  i.e. Software logic 
with options etc.

> It might say that all invalid DISCARDABLE email "SHOULD" be marked as such  

Currently the specification says to discard.  I personally think it 
would rubber against the specs if an implementor added an option:

      [X] Do not discard invalid DISCARDABLE mail. Mark it only.

Possible, sure. But IMV go against the specs.  At least it would be 
enabled by default.  However, I can see that for the more ambiguous 
ALL policy:

      [_] Discard invalid ALL mail.

Here it is off by default and invalid ALL mail is marked only.  Here I 
think, the intentional ambiguous ALL policy leaves it open ended and 
allows for local policy to decide.  No problem here.

> contrary to anything currently on the Standards Track.

I agree with your overall notes, but I do think that the exception is 
that there is a clear MUST Discard for invalid discardable mail that 
is independent from any anything else.  The main reason of course is 
that it must cover legacy transactions (mail without any additional 
and related DKIM DNA)

> seem to suggest that something of the sort is needed).

IMV, the only issue is that it adds more complexity. IMV, before we 
can even come up with an algorithm, we need have some basic framework 
that is presumed everyone will follow or rather be consistent.  IMV, 
unrestricted resigners conflicts with the very notion of what ADSP 
attempts to protect again.  So there has to be a decision of resigners 
SHOULD|MUST follow it.  Only then, IMV, can software developers and 
operators using scripts, or ACL, can create a consistent framework. 
Otherwise we will continue to see these debates and issues come up.

Seriously, I am stuck.  For our WCSMTP receiver, I can easily see 
where it can be optional.  No Sweat. We will support it, but I can see 
where lack of support here is not going to break anything other than 
not help protect spoofed domains.  But not when the mail is for our 
WCLISTSERVE and it has (re)signer features. Ignoring the idea that a 
domain has ADSP is problematic here.   We could go ahead and just 
honor ADSP and be the only system that does so.  I guess that would 
work.  Heck, that might even be a marketing advantage!  But it would 
surely be nice if there was a network "expectation" to play by the 
same rules so that domains can be protected at these other systems as 
well.

==

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 16 Oct 2009 11:28:22 +0100

--On 14 October 2009 09:39:42 -0700 Steve Atkins <[email-masked]> 
wrote:

> statements, that sort of thing - which should never go to mailing lists 
anyway as
> or not at all.
> might use discardable that's fine, but lets be specific about the 
operational
> solely in the abstract protects the discussion from common sense.)

That seems sensible to me. So lists should not forward email that they're 
about to render 'discardable' by breaking the signature. Instead, they 
should reject (5xx) or bounce (DSN) the message. Presumably, a bank wants 
to know if it has a bad email address for a customer. Of course, if you 
aren't going to break the signature, or are rewriting the From: address, 
then it's OK to forward the email. Oh, and if the list sees incoming mail 
already has a broken signature, or none at all, then it should be discarded 
by the list software (or its MTA).

If a list does nevertheless forward an email, after rendering it 
'discardable', of course RFC 5617 says that it should be discarded by the 
MDA. It also occurs to me that 'discardable' means that you can deploy 
per-recipient policies after seeing the message body - by passing the 
message to some recipients, but not others. That's not usually possible.

The treatment of email with authors in a domain with 'dkim=discardable' 
policy seems absolutely straightforward. What's more complicated is the 
treatment of email with authors in a domain with 'dkim=all' policy. There's 
no guidance about handling such mail.

List operators need to be advised that breaking signatures in such domains 
may result in the message becoming undeliverable, even though the inbound 
message carried a valid signature. There are several actions that a list 
could take, to mitigate consequential problems:

1. Not apply VERP bounce policies to messages that are consequently 
rejected. This risks eroding the value of VERP if 'dkim=all' becomes widely 
deployed among domains used by the list's members. Eventually, VERP could 
become unusable if it didn't adapt. Oh, but the lists would become unusable 
first, if people are rejecting messages from dkim=all domains. Is there any 
sense in such domains applying lightweight signatures that are less likely 
to be broken by lists? Can such a thing be done without making the 
signatures reuable? Is it possible to sign the From: header, + the subject 
*after* a list prefix, and the body *before* a list footer? Or would these 
just be newly exploitable holes?

2. Make sure they sign their messages, so that recipients have some 
confidence that this isn't a spammer spoofing a trusted list. And, as has 
been suggested, make clear that they've assessed the signature before 
breaking it. OF course, this is spoofable, OF course it relies on a trust 
relationship between the recipient and the list. But, the recipient 
(ideally) knows which lists s/he's subscribed to, and with DKIM can tell 
whether to trust the list. Some MDA or MUA assistance would be really 
useful here.

You know, I'm not sure I'm averse to a world in which a spammer can only 
deliver mail by adding list-id headers for lists that I'm not subscribed 
to! One where most domains publish 'dkim=all', and all my legitimate mail 
has carries a dkim signature, and broken signatures only come mailing lists 
that I've either subscribed to or not.

3. Some fancy munging of the From: header (like VERP, perhaps), in such a 
way that replies could be routed to the sender? Ugh!

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 16 Oct 2009 12:50:23 +0100

On Fri, 16 Oct 2009 00:27:57 +0100, hector <[email-masked]>  
wrote:

> Charles Lindsey wrote:
>
>> There is no SHOULD|MUST about what recipients do....
>
>

At which point some accepted Common Practice would come in handy.

>       [X] Do not discard invalid DISCARDABLE mail. Mark it only.

All the standard says is that you have the full permission of the sender  
if you decide to Discard. At the most, it is a MAY Discard.

>> different from other recipients (whether by adding A-R records, or

The case in question is where there is a valid signature when it arrives  
at the Listadmin. So he has no reason to Discard.

> that it must cover legacy transactions (mail without any additional

But the case we are talking about is where there WAS a valid signature,  
which has since been broken. But there is evidence from the listadmin  
(whom you might choose to trust) that it had been there. In that case, it  
is perfectly reasonable for a recipient to accept the message on the  
grounds that he has credible evidence that there WAS a valid signature.  
and hence that it indeed came from the purported Author.

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 16 Oct 2009 12:05:05 -0600

Ian Eiloart wrote:

> to know if it has a bad email address for a customer.

Yep.

> Of course, if you 
> then it's OK to forward the email.

Probably.

> Oh, and if the list sees incoming mail 

Yep.

> no guidance about handling such mail.

Agreed; we need more operational experience here.

---

From: Franck Martin <[email-masked]>
Date: Sat, 17 Oct 2009 06:23:33 +1200 (FJT)

> > then it's OK to forward the email.
if you are rewriting the from and put the original sender in the sender: field, most MUA will display it like this:

Sent by JD Falk
on the behalf of DKIM-WG

Seems strange to me.

If you rewrite only the From: header then the MUA will display

from: DKIM-WG

then you hope there is a signature of some sort to know who sent the email originally.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Barry Leiba <[email-masked]>
Date: Sun, 18 Oct 2009 20:55:38 -0400

>> then it's OK to forward the email.

Hm.

It's been suggested (often) that a major use case for "discardable" is
a bank sending a bank statement, or the like.  Going by what's said
above, if the bank somehow gets a mailing list address instead of my
correct email address, it will behave this way (slightly
oversimplifying to make a point; please bear with that, because this
is a valid example):

- If the mailing list is configured to prepend "[Listname]" to the
subject lines, then it will reject the message, and the bank will know
there's a problem.

- If the mailing list is NOT configured to change the subject lines,
then it will accept and forward the message.  The bank will not know
there's a problem, and my bank statement will be forwarded to the
whole mailing list.

It seems wrong that the behaviour with an ADSP-compliant mailing list
should depend upon whether the list is configured to alter the subject
line or not.  I suggest that ADSP-compliant mailing lists should be
advised to reject "discardable" messages whether or not they will be
breaking the signature.

The point here, I suppose, is that forwarders that are meant to
forward to a single individual (as happens with my
<[email-masked]> address) are one species, and should get one
set of advice, while forwarders that are meant to fan out to multiple
recipients (as with mailing lists) are a different species, and should
get different advice.  And that latter advice very much depends upon
what we mean "discardable" to be for.

Barry

---

From: John Levine <[email-masked]>
Date: 19 Oct 2009 01:18:04 -0000

>forward ... while forwarders that are meant to fan out to multiple
>recipients ... should get different advice.

This is the mailing list advice that I strongly suggest we NOT attempt
to provide at this point.  All these arguments about what to do with
DKIM and ADSP and mailing lists are based on pure speculation.

I know what my lists do (just out of curiosity, how many other people
in this argument host active lists?) and I know what works for me, but
there are a lot of other opinions and we won't know what works until
we have some actual experience.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 18 Oct 2009 18:22:20 -0700

Barry Leiba wrote:
>     I suggest that ADSP-compliant mailing lists should be

Yes, this is a reasonable idea.

The question is whether it is the /right/ idea.

Another reasonable idea is that the mailing list should ignore ADSP, since ADSP 
is really meant for final recipients; note that ADSP only comes into play for 
recipients who support it.  (Well, that is at least one model.) And there are no 
doubt lots of other reasonable ideas.

At this stage, I believe rightness depends entirely on market preferences.  Do 
we have any empirical data of ADSP use which experiences the problem being 
covered here, resolves it in the way being suggested, and garners receiver support?

Absent any of that, this discussion is purely academic.

Each proposal like this is expensive.  It takes time to discussion, run through 
the process, test, deploy and use.  We should let private experiments determine 
the preferred handling, before we seek to standardize a solution.

Particularly since we seem to have only and exactly one market-based 
organization experiencing the problem.

Really.

d/
-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Sun, 18 Oct 2009 22:15:20 -0400

> to provide at this point.
...
> we have some actual experience.

Geez, and here this is what I've been saying, and I got sucked into
the speculation anyway.  Thanks for throwing me a line.

Barry

---

From: "John R. Levine" <[email-masked]>
Date: 18 Oct 2009 23:36:11 -0400

> strongly disagree. Filtering early is more likely to pickup signature 
> breakage and protect the down stream recipient. Its more likely to 
> reject back to the sender if they configured stuff wrong.

> Advice could be split between forwarders that break signature and those that
> done. Keep in mind the dkim goal of is message integrity not reputation
> (despite its usefulness here).

This is exactly the kind of speculation to which I was referring.  Nobody 
at this point has more than the most rudimentary experience with DKIM and 
mailing lists, nobody has any experience with ADSP at all.  I won't rehash 
all the reasons that the mailing list "message integrity" argument is 
utterly wrongheaded, but there is clearly no consensus on it.  So stop it, 
already.

Go write some software, use it, and come back and tell us about your 
experience with it.

R's,
John

---

From: Daniel Black <[email-masked]>
Date: Mon, 19 Oct 2009 13:38:41 +1100

Hey Dave,

> > advised to reject "discardable" messages whether or not they will be
rejection is really only needed if they break the signature which should be 
evident by their settings. The point of DKIM is to preserve integrity however 
the bank statement is a confidentiality issue.

For instance I manage a private maillist of board members that receive paypal 
notices. 100% DKIM validation pass rate. The maillist is configured to not 
modify the message so the final recipients could validate it too if they 
wanted.

> Another reasonable idea is that the mailing list should ignore ADSP, since
>  ADSP is really meant for final recipients;

As the mailing list is probably the last place to see a valid signature 
evaluating the ADSP there is the best idea. The mailing list verifier has a 
greater confidence in rejecting broken signatures there than the final 
recipient. The final recipient could deploy some whitelisting model based on 
the behaviour of the list with minimal risk.

>  note that ADSP only comes into
>  play for recipients who support it.  (Well, that is at least one model.)
>  And there are no doubt lots of other reasonable ideas.
> 
> At this stage, I believe rightness depends entirely on market preferences. 
>  Do we have any empirical data of ADSP use which experiences the problem
>  being covered here,

Some was described here;
http://mipassoc.org/pipermail/ietf-dkim/2009q4/012596.html

>  resolves it in the way being suggested,
dkim=discard is the easy case. 

>  and garners  receiver support?
at the moment receivers who care about dkim whitelist domains/ip or if they 
wish to accept some risk, rely on domain reputation.

> Each proposal like this is expensive.  It takes time to discussion, run
>  through the process, test, deploy and use.  We should let private
>  experiments determine the preferred handling, before we seek to
>  standardize a solution.
> 

given the level of ADSP deployment it is hardly unexpected that only one 
organisation that this group collectively knows about has disclosed a problem.

---

From: Daniel Black <[email-masked]>
Date: Mon, 19 Oct 2009 14:06:53 +1100

> to provide at this point.

strongly disagree. Filtering early is more likely to pickup signature breakage 
and protect the down stream recipient. Its more likely to reject back to the 
sender if they configured stuff wrong.

> All these arguments about what to do with
Rejecting mail based on signature failure combined with dkim=all/discard is 
working quite well on the mail lists I manage. I don't do this on the final 
recipient domain though.

> in this argument host active lists?
me - lists.cacert.org

> ) and I know what works for me, but

Though involvement with Sympa and Mailman devs, who for the most part are sick 
of request saying change this so I can fillter spam/forgeries, still want to 
provide unsubscribe links and bottoms of email and generally meet the user 
requested features.

Responses based on shared experience has been:
- Sympa Dev - Serge Aumont - DKIMfriendly switch
http://mipassoc.org/pipermail/dkim-
dev/attachments/20090930/e767bd81/attachment.html
http://www.sympa.org/manual/dkim#summary_of_parameters

- Mailman Dev - Barry Warsaw - mta problem
http://mail.python.org/pipermail/mailman-developers/2009-October/020818.html

- Mailman Dev -Stephen Turnbull - develop List Domain Signing Practices
http://mail.python.org/pipermail/mailman-developers/2009-October/020814.html

- Infrastructure Manger - Ian Eiloart - reject when signature breaks and ADSP 
says all/discardable
http://mail.python.org/pipermail/mailman-developers/2009-October/020805.html

There's plenty of experience. Just need to look a bit beyond this list.

---

From: hector <[email-masked]>
Date: Mon, 19 Oct 2009 04:43:47 -0400

> Go write some software, use it, and come back and tell us about your 

John,

Engineering Speculation not a bad thing.  It may help explain why 
there is no adoption of ADSP which doesn't help DKIM usefulness 
question and adoption rate itself.  Engineers have speculated that 
remailers are in conflict with ADSP implementations.  I personally 
would not call that a speculation because its a truth fact.

I can not see how mail system software developers or hosting system 
can support ADSP until the remailer question is resolved.  Its a 
classic chicken and egg situation:

   - Will remailers support it once a certain threshold of
     amount of domains support it? or

   - Will domains begin to add ADSP records once they
     know remailers will support the ADSP??

   - Will domains begin to add ADSP records in preparation
     that one day receivers and remailers will support the
     ADSP?

Are you now recommending that software developers add ADSP-compliant 
Forwarder/Remailer support so we learn and prove what we already know 
will happen?

I am just not sure what you want us to come back and report.

  1) Remailers are seeing problems because little to no
     domains supports ADSP records.

  2) Remailers are seeing an increasing of rejects/discards
     related to ADSP domains

     x% due to genuine spoofs
     y% due to members with ADSP Domains

What empirical evidence are you looking for?

I think it is pretty good engineering speculation that remailers are 
in conflict with ADSP domains.

--
HLS

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 19 Oct 2009 11:01:20 +0100

> we have some actual experience.

I host 920 current lists, and have hosted a similar number that are no 
longer in use.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 19 Oct 2009 10:54:34 +0100

--On 18 October 2009 20:55:38 -0400 Barry Leiba 
<[email-masked]> wrote:

>>> That seems sensible to me. So lists should not forward email that
>>> they're about to render 'discardable' by breaking the signature.
>>> Instead, they should reject (5xx) or bounce (DSN) the message.
>>> Presumably, a bank wants to know if it has a bad email address for a
>>> customer.
>>
>> Yep.
>>
>>> Of course, if you

Right. One needs to take more care about the addresses that one gives to 
one's bank. Don't forget that, for most lists, the bank's email address 
would also need to be subscribed to the list. For an *announcement* list, 
even that's not good enough.

> advised to reject "discardable" messages whether or not they will be

That's not, afaiks, required or even implied by the RFC.

Another feasible use case would be an emergency alert system, in which it's 
important that the content isn't changed. So, we'd be using ADSP to ensure 
the integrity of alerts.

Perhaps there's a case for adding tags to allow domains to advertise 
whether their concern is privacy, integrity or both, perhaps 
"dkim=discardable-privacy", "dkim=discardable-accuracy", 
"dkim=discardable-privacy,accuracy".

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 19 Oct 2009 10:42:50 +0100

>>
> if you are rewriting the from and put the original sender in the sender:
> field, most MUA will display it like this:
>
> Sent by JD Falk
> on the behalf of DKIM-WG

Most? Only Outlook as far as I'm aware. Anyway, the use case here is an 
announcement only mailing list, not a discussion list. In that context, 
it's perfectly natural. Like this: "Sent by JD Falk on behalf of Return 
Path Services", or some such.

I'm NOT saying we should change the From header where we don't already. I'm 
saying that for those lists where we already change the From header, we 
don't need to do anything special for ADSP.

> then you hope there is a signature of some sort to know who sent the

Maybe, but when you get an email from a mailing list, it's the list that 
you need to assess, not the original sender. For announcement lists, you'd 
hope that the list is quite well locked down.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 19 Oct 2009 09:52:31 -0700

I haven't seen the various lists proposals but two things:

1) what to do with ADSP discard is a legitimate discussion for list software
2) what to do with ALL is NOT. A list that discards or otherwise rejects a
    submission *solely* on ALL is BROKEN. Doubly so if the ALL message had
    a legitimate signature on input to the list.

My feeling is this:

1) Make DISCARD rejection a knob and see how it goes.
2) For ALL or just plain old DKIM signatures, use that information as an
    end receiver would to make a spam/ham decision, but otherwise pass *everything*
    through to the final recipient even if they're 100% sure they broke the
    signature. (Forensics)
3) Always resign the message if it's possible.

Mike

---

From: hector <[email-masked]>
Date: Mon, 19 Oct 2009 13:27:40 -0400

I agree with most of this.

We need to trust software people and operators - in principle they are 
not going to do something the specification does not say and is very 
clear about it.  We cane skeptical about it, but good engineering 
faith is all we have. IMO, ADSP "discardable" is very clear.  ADSP 
"all" is not and as you implied, and I always thought was understood, 
it is good for warnings, Logging, Learning, AI, scoring, feed to 
reputations or other new classifications methods, what have you. We 
can build with all.

But overall, its all for nothing if we exempt remailers for ADSP 
considerations.

We should leave it up to implementations about how they want to 
challenge DKIM=ALL domains that arrive into their network.

What is ironic about all this DKIM forwarding issue is the same issue 
that SPF forwarding had.  This was one of the marketing advantages of 
DKIM - that it didn't have a forwarding problem.

Well, it does.

--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 19 Oct 2009 10:14:05 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Michael Thomas
> Sent: Monday, October 19, 2009 9:53 AM
> To: Daniel Black
> Cc: [email-masked]; [email-masked]
> Subject: Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5
> (ADSP/Forwader) conflict
> 
> My feeling is this:
> 

The open source implementations I have do it this way.  Unfortunately I don't have any data to report from users yet.

Perhaps I can add some anonymous-as-possible off-by-default well-documented stats and data collection and ask people to turn it on during the experimental period.  It seems easier to do something like that than asking users to send me data after the fact.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Oct 2009 13:46:58 -0400

> DKIM - that it didn't have a forwarding problem.

Indeed it does.  But it doesn't have the forwarding problem for the
(large) class of forwarders that we might rather call "aliases" -- the
ones such as computer.org, acm.org, and college alumni aliases.
That's a major and common case that breaks SPF, but that DKIM works
with.

It's also possible -- we'll have to see what happens -- that mailing
lists could change their behaviour to take better advantage of DKIM
(with the specs that are already published).  That's not an option
they had with SPF.

So I think the fact that mailing lists aren't straightforward with
respect to any "sender authentication system" doesn't mean that DKIM
hasn't moved us well ahead in this regard.

Barry, as participant

---

From: hector <[email-masked]>
Date: Mon, 19 Oct 2009 14:25:17 -0400

> That's a major and common case that breaks SPF, but that DKIM works

Unless I don't follow, computer.org does not have a policy record, so 
its not really the same issue. Right?

> (with the specs that are already published).  That's not an option

No doubt. DKIM/SSP did have a better solution regarding remailers. 
That is why people loved it - especially me. But that was when policy 
and 3rd party considerations was part of the picture.

For example, you could of had for example, a op=- SSP policy for 
computer.org which would allow mipassoc.org to break and resign your mail.

Right now, your domain is spoofable.

In effect, the SPF forwarders problem was carried over to DKIM when we 
removed the 3rd party policies.  Kludges were developed for SPF and it 
appears that might happen with DKIM=ALL now.

> hasn't moved us well ahead in this regard.

I agree. I will express as

    DKIM + SSP  =  4 steps ahead
    DKIM + ADSP =  2 steps backwards

We are still 2 step ahead.

<grin>

==

---

From: John Levine <[email-masked]>
Date: 20 Oct 2009 03:04:21 -0000

>> 2) For ALL or just plain old DKIM signatures, use that information
>>     as an end receiver would to make a spam/ham decision, but
>>     otherwise pass *everything* through to the final recipient even
>>     if they're 100% sure they broke the signature. (Forensics)

>The open source implementations I have do it this way.  Unfortunately I
>don't have any data to report from users yet.

Gee, Mike and I agree.  (Alert the media!)  My DISCARD knob will always
be off, of course, but I expect to use whatever data I can get to decide
what to allow through the list and what not to.

R's,
John

---

From: John Levine <[email-masked]>
Date: 20 Oct 2009 03:13:23 -0000

>> Well, it does. ...

>(with the specs that are already published).  That's not an option

The sensible way for lists to change their behavior is to SIGN THE
MAIL THEY SEND. 

People apparently seem to have trouble distinguishing between mail Bob
sent directly to you, and mail that Bob sent to a list which decorated
his message and then passed along to you.  DKIM makes that easy to
handle -- when the list signs its mail, you can reliably tell that no
matter what's on the From line, this message is from the list so you
can do whatever you do with list mail without having to worry about
who sent it to the list in the first place, just like you do now.

Ironically, this is also a situation that SPF handles adequately;
lists invariably apply their own bounce addresses to do automated
bounce management, so as far as SPF is concerned, mail from the list
is from the list.  Sender-Id doesn't work so good here, though.

R's,
John

---

From: hector <[email-masked]>
Date: Tue, 20 Oct 2009 01:18:15 -0400

John,

I don't think there is an issue with the little angel sitting on the 
left side of the shoulder, but the little devil that is sitting on the 
right.

Unless there is suggestion that we have some List-ID whitelist 
inclusion concept or some other reputation concept, in lieu of this, 
we are not protecting domains from the little devil.

A mechanism that claims to protect one side, needs to cover the other 
side as well.  The Remailer needs to consider the BAD side is the DKIM 
  coin.

It is not enough for receivers to see 3rd signatures that has good 
information about, but what the receiver does not get about them.

Again, there are two parts to the implementation that makes it 
prohibitive to adopt:

   1) Receivers
   2) Receivers/Remailers

The receivers can filter the ADSP based 3rd party signature violations.

At the #1 receiver it is final destination. There is no forwarding to 
occur.  No issue here, and there is no issue with #1 not supporting 
ADSP.

The same is true with the #2 receiver component.

However, when it comes to the #2 remailers, it becomes more sensitive. 
    It can no longer ignore the ADSP protected domain allowed in by #2 
Receiver regardless if #2 receivers supported ADSP or not.

I know what we can do to our #2 Remailer:

   1) Common to all or most list systems.

      The submission user has to be a member, if not, its not
      processed.

   2) Filter ADSP domains, do not process it.

PRO:

   - Spoofed member domain submissions are protected

   - No membership downlink reject problems.

   - No membership threat of subscription removal.

CON:

   - Member Domains that mistakenly use a restricted
     policy are filtered.

If remailers do not honor ADSP, you can effectively swap the PROs and 
the CONs:

PRO:

   - Member Domains that mistakenly used a restricted
     policy are ALLOW to be submitted.

CON:

   - Spoofed member domain submissions are no longer protected

   - Membership downlinks create reject problem.

   - Membership threat of subscription removal.

I do not think that is just pure speculation. But software engineering 
  intuition and foresight.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 23 Oct 2009 16:03:31 +0100

--On 23 October 2009 10:29:17 -0400 "John R. Levine" <[email-masked]> wrote:

>>> If, as I suspect, bad guys spoofing their way onto lists past admins
>>> unwilling to do inbound filtering is not an actual problem, perhaps we
>>> could agree not to waste time inventing mechanisms to solve it?
>>
>> I don't think that's what people have been worried about. I think
>> they've  been worried about spammers adding list headers to messages, in
>> order to  remove the ADSP protection. There's also the possibility of
>> spammers  subscribing to lists. Still, a well managed list should have a
>> good  reputation, and I don't see much list abuse.
>
> This strikes me as an even more arcane and implausible threat. Since
> spammers don't add fake list headers to evade filtering now, why would
> they start now?

Well, they won't do it yet. They may start to do it if it becomes hard to 
deliver email otherwise. With future widespread MSA, DKIM, ADSP and SPF, I 
think it's theoretically possible that all mail could be checked for 
authorisation some day. Therefore, spammers will need to look for ways to 
sponge off domains with good reputations (newly registered domains won't 
have good reputations). Forging list-id headers might be a way to do it.

> Wouldn't the correct response be for lists to sign their mail to help
> recipients recognize real list mail?  That has the advantage of requiring
> no changes to any IETF document.

Absolutely.

>> I agree that we don't need additional mechanisms, but think we do need
>> better  clarity on the distinction betweem dkim=all and dkim=discardable.
>
> Since ADSP is useless to the 99.99% of domains that are not phish targets
> like Paypal (and probably useless even there), that would be an extremely
> poor use of limited resources.  It would be much more useful to help
> people who write and use list software get the lists to sign their mail
> so you can whitelist real list mail from lists you know.

All sites with good email sender reputation are phish targets these days. 
We're seeing spear phishing attempts several times per week nowadays. 
Success generally results in web mail accounts being used to send 419 
scams, or further phishing. Phishers value our accounts enough that they'll 
enter an exchange of emails with a user in order to convince the user to 
give up a password.

I'm not sure that I can see a business case for anyone else to use our 
addresses in From: headers. Certainly not without prior arrangement, and 
DKIM delegation can allow that. So, I can see value in ADSP for our site.

Anyway, the point of clarifying the distinction is to prevent people making 
the mistake that you seem to be expecting them to make.