On Mon, 12 Oct 2009, Ian Eiloart wrote:
It also seems to me that there must be a difference between "dkim=all" and
"dkim=discard". Publishing "discard" should mean that there's no
My understanding is that the all/discard distinction is orthogonal to
the mailing list issue.
I think the motivation for discard is to give guidance when someone
realizes a message seems to be forged after it has already been accepted
by their MX. This could happen, say, if a user at a DKIM-unaware ISP
installed a DKIM-analysing plugin into their MUA.
In this situation, there are only three choices:
1. Send a bounce message
2. Drop it silently
3. Ignore the validation failure and show it to the user anyway.
#1 is clearly unacceptable in this day and age, since in the frequent
case that the message was indeed forged, the bounce would be backscatter.
(Unless perhaps SPF asserted the provenance of the bounce address.)
dkim=discard hints that people in this situation should take option #2.
It would be appropriate for sites that really, really, don't want their
users to ever see a phish.
dkim=all hints that people in this situation should take option #3. It
makes mail less likely to be mysteriously lost if there is a screwup in
the signing of the legitimate mailstream.
Ideally, of course, all improperly signed mail would be rejected at CR LF
'.' CR LF, and this distinction would be irrelevant.
discard, all, and except_mlist thus cover three corners of a
square.
In theory we could have a fourth option, that provides for silent discard
of mail that fails DKIM and is clearly not legitimate mailing list
traffic. But I don't think anyone would ever use it.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html