[mail-vet-discuss] New draft for review
sm at resistor.net
Tue May 29 10:43:47 PDT 2007
At 18:14 28-05-2007, John Levine wrote:
>Mostly it looks good, but I have a few questions:
> >> An MTA adding this header in either form MUST use its own hostname
> >> only. It MUST be a fully-qualified domain name.
>How come? In a setup where there is a farm of equivalent MTAs, I
>don't see the advantage of having it say in-23.atl.mail.earthlink.net
>rather than mail.earthlink.net or just earthlink.net. It's important
>to know who added the header, but I don't care which of an ISP's 200
>MTAs did it.
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. 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. 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.
> >> MTAs that are relaying mail rather than delivering it MAY
> >> perform sender authentication or even take actions based on the
> >> results found, but MUST NOT add a "Authentication-Results"
> >> header if relaying rather than rejecting or discarding at the
> >> gateway.
>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
Why would you use an Authentication-Results header which wasn't added
within the trust domain? The header can easily be spoofed.
More information about the mail-vet-discuss