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 <[email protected]> _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
