John,
As one of my colleagues would say, please peel yourself off the ceiling
and relax. I did not say you lied. I just do not agree that your usage
case is a slam dunk. Furthermore, your explanation is, at best, vague.
trivial amount of extra work to check another hop or two and look at
AR's added farther away.
Wait a second! More than one mailbox in the case you discuss means more
than one border gateway with differing sets of policies and is
inapplicable to what we're talking about here.
Huh? Where does it say that people with more than one mailbox aren't
allowed to use A-R ?
You absolutely are. But consider this: MUAs already handle multiple
mailboxes with multiple sets of logic for each. For instance, whether
or not you enable Baysean filtering in Thunderbird is per-mailbox. And
just about all MUAs do rule sets on a per mailbox basis. Given that you
can have different authoritative ARs for each mailbox. The
administrative domain of each mailbox for purposes of the AR are going
to be different. There is no reason to believe that the path to one
mailbox is going to be anything near the path to the other. In any
event, whichever path is taken, it is the border MTA relative to each
mailbox that will add the AR, and hence strip others.
In other words, if you have a gmail account and a yahoo account, there
is no reason to believe that either gmail or yahoo will see the other's
messages unless you are forwarding one to the other. Now let's look at
that specific case. Let's say that you are forwarding your yahoo mail
to your gmail account (for instance). Assuming the message is forwarded
unmolested, gmail will be able to verify any DKIM signatures found and
slap on an AR header that you can then do what with you will. On the
other hand, if you want to do an SPF check, there things will probably
go bust, because Y! is not in the authorized list of forwarders for any
specific message. To remedy that situation you have to leave a gaping
security hole for all others.
The point I'm making here isn't about different policies, it's that
you can only believe an A-R header if the path it took to get to you
is good. We don't all get our mail via a VPN direct to Cisco global
HQ, you know, and the more unlike that a mail system is, the more
likely it is that A-R will be useful.
This is why I don't argue for a MUST strip headers. I don't claim to
know all of the world, but Cisco's enterprise email configuration is
very common (aside from its size).
Well, it's not clear we are offering anybody any favors with this header
to begin with. The game is likely lost by the time the message gets to
the user's desktop.
Perhaps, but in that case A-R is totally useless, so why waste your
time on it?
Because it can do harm if done wrong. Providing a false sense of
security is not helpful.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html