[mail-vet-discuss] New draft for review

[John Levine]

>> 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.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