Frank Ellermann:
It can be both correct: Let's take a realistic example, GMail
starts to offer forwarding, but adds some ads plus their own
signature, destroying the signature of bank.com. If we have
a couple of "MUST reject" and implementations actually doing
this they might give up. Something has to give, bank.com, the
munger, the verifier, or the user.
When mail has a valid bank DKIM signature we have assurance that
it was sent by the bank. The rfc2822.from is of minor relevance,
because we already know from the DKIM signature that it was sent
by the bank.
When mail has a valid gmail.com DKIM signature, but no valid bank
signature, then all we know is that it came via gmail. Whatever is
in rfc2822.from is merely hearsay and should be treated as such.
There is no reason to delete the mail.
The problem that you refer to is due to the mistaken belief that
DKIM signatures imply anything about rfc2822.from addresses. We
can eliminate the problem by simply taking DKIM signatures for what
they actually are: proof about the identity of the signing party,
not proof about the identity of the author. =============
Wietse
With mail I expect the worst, the crap is dumped with a big
red "fishy" icon into the mailbox of the unhappy user. The
user will delete it unread, bank.com will give up its SSP,
the verifier gives up to use DKIM... tell me why I'm wrong.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html