--On 16 October 2009 06:33:08 -0700 Michael Deutschmann <[email protected]> wrote:
> 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?) "dkim=all" If you read ADSP in conjunction with section 3.1 of RFC 5016, then "dkim=all" means exactly that: "Domain Alice provides information that it signs all outgoing mail, but places no expectation on whether it will arrive with an intact first party signature." <http://tools.ietf.org/html/rfc5016#section-3.1> > -- > > 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 -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
