I don't see the advantage of having it say
in-23.atl.mail.earthlink.net rather than mail.earthlink.net.
Agents use the identifier, the FQDN in this case, to determine
whether the Authentication-Results header can be trusted. The FQDN
may not the best choice in the case of mail farms.
Well, yeah. Seems to me that mail farms are likely to apply the
majority of these headers, so we better have something that works
with them.
From a usability point of view, the ISP may prefer mail.example.com
as an identifier. Using that may be a problem though as the header
may also be used to convey results to downstream filters which would
be using the same identifier.
If they're all inside the same network, that's really not our problem.
Through the magic of "as if", they can do all sorts of local magic so
long as someone at the other end, the user with his MUA, sees it as
one header application.
In your example, we would have to remove all Authentication-Results
headers with earthlink.net in them prior to authentication tests to
avoid security issues.
Right. Keeping in mind that this only applies to externally visible
hops and not how they implement their internal network, why is that a
problem?
Again, how come? I have a bunch of forwarding addresses like
uucp(_at_)computer(_dot_)org, I already special case the mail that comes
through
the forwards, and if there were an authentication results header, I'd
use it.
Why would you use an Authentication-Results header which wasn't added
within the trust domain? The header can easily be spoofed.
Because I know the path that mail from those particular domains takes,
and if a message arrives over the right path it is in effect part of
my trust domain. This isn't hypothetical, I really do it now by
parsing Received headers through the hops on systems I trust. While
I'm at it, there's no reason not to parse and interpret
Authentication-Results headers, too.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html