ietf-dkim
[Top] [All Lists]

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

2009-10-14 07:51:22


--On 14 October 2009 10:32:32 +0100 Charles Lindsey 
<chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk> 
wrote:

On Tue, 13 Oct 2009 22:27:52 +0100, hector 
<gmail(_dot_)sant9442(_at_)winserver(_dot_)com>
 wrote:

Charles Lindsey wrote:

On Tue, 13 Oct 2009 02:24:56 +0100, hector
<gmail(_dot_)sant9442(_at_)winserver(_dot_)com>
wrote:

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.

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.


But what is its not there?    DKIM=DISCARDABLE provides a Domain
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.

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.


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).



-- 
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