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-users(_at_)lists(_dot_)sourceforge(_dot_)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