Hi John,
At 14:25 29-05-2007, John Levine wrote:
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.
Agreed.
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.
I was going to suggest that the FQDN be replaced by a unique
identifier with a recommendation that it may be a FQDN. We cannot
really call it unique though if it is going to be used on more than one host.
A "small site" can use the FQDN. A mail farm, as in your example,
can determine what kind of identifier suits their needs. The problem
is that we cannot put just any string there as we are assigning trust
based on that identifier string.
The other issue is that the MUA may be parsing that header only. If
I have two accounts, one with example.com and the other with
example.net, each with a different provider, My MUA would trust the
mail.example.com and smtp.example.net identifiers. As the filter at
mail.example.com would only remove any instance of a header with its
identifier, a message coming through mail.example.com with an
Authentication-Results: smtp.example.net header would be trusted.
> 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?
I don't see that as a problem.
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.
I'm sure you know that and you can do it correctly. :-) We cannot
use that as a general rule unless we have a tie-in with the Received
headers appended by hosts we trust. The current version of the draft
does not have that.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html