ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Lists "BCP" draft available

2010-05-18 10:40:04
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 <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html