SM 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. Conversely, an
MTA doing local delivery MUST add this header prior to delivery the
message in order to be compliant.
Conversely, an MTA MUST add this header prior to the delivery of the
message in order to be compliant.
Why that change?
It was a rewording of the last sentence.
Hi all,
I have to say that I don't understand that paragraph at all. That,
and some other messages in this thread seem to suggest that auth-res
is only for MUA's consumption. I don't think that's the case at all,
and that the draft needn't pick who should and shouldn't use the
information -- only make clear the security considerations of when
it ought to be deemed trustworthy.
As an example, our implementation saves the auth-res in our MTA logs
and a grinder goes through those logs to generate stats, including
verification stats. This is arguably the same MTA that's reusing its
own auth-res :) This and other uses should be perfectly legal and
encouraged.
Mike
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html