Ian Eiloart wrote:
--On 4 October 2010 18:24:11 -0400 Hector Santos
<hsantos(_at_)isdg(_dot_)net> wrote:
It has been observed by implementations that is it possible to replay
a message with a 2nd 5322.From header at the top which wouldn't break
the DKIM signature validity, but would often be displayed by MUAs to
display the new 5322.From display rather than the signature bound
5322.From header.
Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to
display the signed header? Are there really MUA's that will display the
unsigned headers *and* assert that it was validated? If so, that's
surely a bug in the implementation of the MUA.
Ian, it would be not practical to expect MUAs to address this. But
sure a recommendation for MTAs and MUA to validate RFC522 specifically
in regards to 5322.From would suffice.
As Keith Moore recently stated in IETF-822:
"Okay, I'll state it with more precision: The checking of
headers should only occur when such a feature is actually being
used: e.g. when the message is actually being submitted, being
filtered for spam specifically on behalf of a sender or recipient,
or being gatewayed into (or out of) a foreign (non-Internet)
mail system."
His point, in IMV, is that you are not going to find many MTA doing
RFC 822/2822/5322 checking unless it has a specific purpose.
A DKIM ready ADMD or MTA receiver might be able to reject/drop invalid
mail with multiple 5322.From lines. We added a script for this
ourselves.
But to cover all loopholes the DKIM-verifier MUST have an additional
requirement to fault a message with 2 or more 5322.From lines.
That is exactly what the ALT-N open source DKIM/ADSP API did - added
an additional requirement for DKIM verification that is above and
beyond what the current specs says and currently allows.
The whole point of a BIS is to help codify the implementation field
testing and experiences which alter or fine tunes the proposed draft
protocol.
This one chalks up as on par with what we are seeking.
--
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