On 18 May 2010, John Levine wrote: > Agreed. We have no idea what "all" means in practice, other than perhaps > an ill-defined small decrement to some sort of reputation if the signature > isn't present.
If I were in charge, I'd retire "all", to be replaced with two new options with clearer semantics. One would be the "except-mlist" I proposed a few months back. The other would be "rejectable". "rejectable" would indicate that all missing/bogus signature mail is to be rejected -- the reciever is not to worry about the possibility that the message went through a mailing list. "rejectable" would differ from "discardable" only in the case of a validator that has no ability to reject in-transaction. The most obvious case would be a DKIM-checking plugin for an MUA using POP3 with a DKIM-unaware ISP. "discardable" would tell the MUA that it is ok to simply drop invalid messages. "rejectable" would indicate that, should it be impossible to send the problem message backwards, it is better to let it go forward to the end user than to blackhole it. "discardable" would be the choice for those paranoid about phishing in their name. "rejectable" would be for those who are eligible to use "discardable", but prefer not to risk mail *silently* disappearing should a bug cause the signature to appear bad to some receivers. Sending a bounce message would comply with the spirit of rejectable, but that is not wise in general as the internet is beginning to punish backscatter. Unless the problem message's MAIL FROM: is independently proved valid (eg: by SPF), discarding or delivery are the only choices a late-acting validator has. (One note referencing things upthread: Back when I proposed "except-mlist", most objections were on the basis that there is no *automatic* way for the reciever to implement it differently from "unknown"; only vanity-domain recipients can benefit. But it would be correct for a mailing list input mailserver to treat "except-mlist" as "rejectable", since lists don't mail to each other.) ---- Michael Deutschmann <[email protected]> _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
