On 08/Oct/10 18:33, Dave CROCKER wrote: > On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote: >> I'm still cringing at the layering violation of "fixing" in DKIM >> the fact that many RFC5322 implementations, MTAs, MSAs and MUAs >> alike, don't bother to enforce normative portions of that >> specification. >> >> Is there precedent of this being done elsewhere, i.e. >> compensating in one protocol for abundant lousy implementations >> of a layer below it?
I don't know of a precedent standard, but I recall of an MTA that did bother to enforce normative portions. Users periodically complained, because it is not quite practical to not be liberal in what we accept. The best of users' protests that I recall was No, just to deliver mail rather than being a pedantic-mode SMTP debugger. [http://www.mail-archive.com/courier-us...@lists.sourceforge.net/msg16896.html] > I'm a bit confused. > > We want to re-submit DKIM Signing to Proposed Standard, in order to > fix an edge condition that is only a theoretical issue and only > fixes a problem that is actually outside of the scope of what DKIM > is trying to achieve? Hmm... it is only theoretical until it becomes productive to put it into practice, and at that point it will be too late. No doubt most of us will update their to-be-signed field lists during the next few weeks. However, introducing what I called "a handy abbreviation" would be a source of confusion. When "h=from:from" will be automatically assumed by verifiers on seeing "h=from", will we still have to specify "h=from:from" in case we hit an older verifier? Otherwise, just to be safe, we may end up with "h=from:from; h2=from;" :-/ In addition, the current "style" of the DKIM specs doesn't dig into the meaning of fields. Rather than being layered on top of 5322, DKIM looks parallel to it: In case one does sign multiple "From"s --as it happened upthread-- the resulting signature looks unambiguously valid. If anything is undefined, it is the 5322 semantics, not that of 4871. Introducing knowledge of what fields may occur what number of times would alter that style. Why not also take into account MIME preambles and epilogues, then? After all, I'd keep that handy abbreviation for a revised canonicalization, whenever it will come. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html