Murray S. Kucherawy wrote:
If we can extract DKIM from the equation entirely and the
problem remains, how is it a DKIM problem?
Because DKIM raises the bar and begins to bind headers that it
required to be *exclusively* correct - a new level of thinking and
concept that is above and beyond any other email requirement we ever had.
That means that all DKIM implementations *MUST* check its own DKIM
requirements. It can no depend on other layers which by its (erroneous)
8.14 premise, there are many that are not compliant with 5322.
Just because the problem predated DKIM does not excuse DKIM from doing
what it suppose to do. All this means is that DKIM verifiers (and
signers) MUST make sure there are no multiple 5322.From.
Remember, the theme premise in section 8.14 is:
Many email implementations do not enforce [RFC5322] with
strictness. As discussed in Section 5.3 DKIM processing
is predicated on a valid mail message as its input.
That alone says DKIM started with a known problem and a requirement
to make sure its input is correct in order to function correctly in
order to cover all loopholes.
This is by far a DKIM issue. The reality is that there are systems
that do perform strict RFC 822/2822/5322 checking. But as I already
shown, there are DKIM implementations that are bypassing it.
Saying RFC 5322 compliance is required is simply not enough. DKIM is
a technology that requires that it checks for such faults.
*Seriously*
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html