On 24 Jun 2011, at 03:46, Douglas Otis wrote:
On 6/23/11 2:52 PM, John R. Levine wrote:
Acceptance policies and results for DKIM MUST align with
what is being displayed in the message.
I'm pretty sure that we have uniformly agreed not to attempt to do MUA
design, so, no, it doesn't. We have no idea what is displayed in the
message. We have no idea if the message will ever be displayed at all.
Ian,
John is right. Most headers are displayed selecting top-down and DKIM
always selects bottom-up. Headers likely displayed and selected to be
signed need to be check by some protocol layer that ensures they are not
illegally pre-pended. Unfortunately, both SMTP and DKIM will not make
these basic checks. There seems to be a prevailing assumption undefined
spam filters will instead intercede. Who should victims blame when
these checks are not made?
They should blame (a) the spammer, and (b) their local MTA operator.
Even though we don't do MUA design, somebody has to. It's helpful if there's a
set of people in the world that have considered these issues, and can give
advice on them.
How can a secure system be specified?
With this particular issue, it seems that an MTA could simply insist that a
message comply with RFC5322's requirement that there be exactly one "From:"
header. Now, we could say in DKIM that a signature is invalid if there's more
than one From: header present in the message. Or we could informally advise MTA
or MUA designers that ignoring RFC5322's requirements here is inadvisable,
since DKIM has that assumption.
For me, as an MTA operator, I'm happy that I have justification for rejecting
messages with the wrong number of From: headers.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html