On Fri, 16 Oct 2009 00:27:57 +0100, hector <[email protected]> wrote:
> Charles Lindsey wrote: > >> There is no SHOULD|MUST about what recipients do.... > > > 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. At which point some accepted Common Practice would come in handy. >> It might say that all invalid DISCARDABLE email "SHOULD" be marked as >> such >> and sent on. > > > 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. 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. >> 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). The case in question is where there is a valid signature when it arrives at the Listadmin. So he has no reason to Discard. > 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) 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. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: [email protected] 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
