[mail-vet-discuss] New draft for review

[SM]

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