On Friday 12 October 2007 17:44, 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.
Isn't trust something the receiver of the relayed mail would decide? I'm
thinking of something like a alumni association forwarder wouldn't know if
receivers chose to trust them or not (and not all receivers would come to the
same conclusion).
If the relaying MTA has to know anything about how MTAs to which it relays
feel about it's trustworthiness, I think that's a substantial administrative
complexity.
I think this should be turned around and left up to receiving MTAs to decide
if they trust the upstream header or not.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html