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(_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.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html