On 22/Oct/10 18:06, Charles Lindsey wrote:
On Thu, 21 Oct 2010 16:17:18 +0100, Alessandro
Vesely<vesely(_at_)tana(_dot_)it>
wrote:
DKIM-Signature: d=Big-IPS.com; h=from; (supposedly)...
From Accounts(_at_)Big-Bank(_dot_)com
From Someone(_at_)Big-IPS(_dot_)com
Subject: Audit notification
<body of text saying anything>
In my hypothesis, a verifier would discard the 2nd "From
Accounts(_at_)Big-Bank(_dot_)com", at least for hashing purposes. If they
were
both signed, PERMFAIL would result from a mismatch in the header-hash.
If Big-Bank had been added after signing, verifiers are already
authorized to delete that field from the message, according to the
current PS. Isn't that enough?
I am am not clear what you are suggesting here. Please clarify. Do you
actually want to pass on to the recipient a message that was different
(i.e. lacked a header) from what came in. If so -1.
That's one possibility. What I have in mind is an MTA filter, not a
MUA extension. The same program may be authorized to silently drop
whole messages to honor "discardable" policies, so I don't think it is
a desecration to drop a spoofed header field when it finds one.
I'd never mandate such behavior, though. It may be made available as
an option when users will solicit it, if ever.
Or if you are saying that the verifier should hash the first From:
(contrary to 4871 with requires it to hash the second), thus triggering a
PERMFAIL, then you are indeed getting the right answer, but by some very
weird means.
I mean first, second in a bottom-up sense. Since the verifier knows
there can only be a single From, it hashes empty strings for any
further one. Of course, if the verification fails, there is no way to
try and discern signed fields...
DKIM-Signature: d=Big-IPS.com; h=from; ...
From: Someone(_at_)Big-IPS(_dot_)com, Accounts(_at_)Big-Bank(_dot_)com
Subject: Audit notification
... (missing Sender)
Isn't that already required to have signatures from each, according to
4871?
No, the signature isn't tied to the domain in the From field(s).
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html