I'd like to more emphatically state the case for adding a
"dkim=except-mlist" policy to ADSP. It will soon become a practical
issue for me, since my mailserver software (Exim) is going to support
DKIM in its next version.
Without it, I'd have to use "dkim=unknown", which is effectively no ADSP
at all.
To review, "dkim=except-mlist" would mean:
I sign everything leaving my bailiwick, but may post to mailing lists
that break the signature. You are *on your own* in telling the
difference between mailing list mail (which may be good despite a
broken signature) and directly sent mail (that is always signed). If
you can't tell, then treat as dkim=unknown (ie: assume a message is
ML traffic unless you know otherwise.).
(Incidentally, anyone have a better name for this policy?)
--
The determination of whether it is good to add a new policy to ADSP
should rest on three issues:
1. Is it backwards compatible?
2. Will senders ever deploy it?
3. Will receivers ever treat it differently than what the senders would
use if it were unavailable?
For #1, it is indeed compatible. RFC 5617 explictly says that unknown
values are to be treated identically to "unknown".
Under Levine's interpretation of RFC 5617, "unknown" is clearly the best
approximation to "except-mlist". Under the Thomas interpetation, it is
a small step back, but enough people endorse the Levine interpretation
that it would be foolish to count on sites treating "all" as
"except-mlist".
For #2, do I even need to argue? Any site that passes all outgoing mail
through a DKIM-aware smarthost qualifies for "except-mlist", but not for
"all" if there are any mailing list subscribers.
#3 is the weakest point, but I can offer my personal testimony that I
have all my mailing lists whitelisted, and could thus only improve my
bad-mail determination accuracy if this extra information was available
in the ADSP records of purported senders.
(By the way, it might be a good idea to pre-reserve a family of policy
names, which would have the property of devolving to "except-mlist"
instead of "unknown" when the validator does not know them specifically.
This would allow 100% backwards-compatible later deployment of schemes
that provide for easier detection of desired mailing list traffic.)
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html