John Levine wrote:
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.
I think it would be better to say that the header should usually be
added by the MX for an address, since that's the only point where you
can check path authentication like SPF and Sender-ID. For content
authentication like DK and DKIM, you can do it anywhere you want, so I
don't see any reason to tell people not to.
I suppose since elsewhere in the document it says border MTAs should
discard any headers they find that they don't want to trust so it's not
a big deal to remove the restriction. My thinking here was to add an
extra place where MTA implementors are discouraged from adding the A-R
header in a place that might confuse someone downstream such as a
hapless user or MUA.
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html