Murray S. Kucherawy wrote:
I incorporated all of these suggestions except:
Eric Allman wrote:
Section 5 says that relaying MTAs SHOULD NOT add an A-R header field,
even if they actually do check the results and take actions on the
basis of the results. That seems like it can create a mystery. I
suggest either changing the text or adding an explanation for this
behavior.
A relaying MTA should only add an A-R header field if the border MTA
which will receive the message trusts the relaying MTA. An example I
added shows how this might be useful.
Thus I guess this should say that a relaying MTA SHOULD NOT add an A-R
field unless it falls within the trust boundary of the domain to which
it is relaying.
I frankly don't think it's anybody's business which mta a should or
should not
add an auth-res. There's nothing we can do to prevent this sort of
behavior, and I certainly wouldn't change mine based on this draft. it's
the job
of the incoming domain to strip out potentially untrusted auth-res anyway.
Mike
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html