On Tue 11/Jun/2019 18:38:15 +0200 Hector Santos wrote: > On 6/11/2019 11:12 AM, Alessandro Vesely wrote: >> >> Section 12.4 seems to have some problems. The first bullet should be >> reworked, >> because it can be understood as suggesting that in cases like, for example: >> >> From: "[email protected] via Bug Tracker" <[email protected]> >> >> a _MUA_ should "execute the DMARC mechanism on the domain name found there >> rather than the domain name discovered originally." That sounds nonsense, >> first, because MUAs should rather base on A-R records added by the MX. > > This is what I meant above. You are proposing a trust concept for the MUA on > which A-R record to "believe." > > The MUA needs trust on the meta-data headers it sees. In theory, it could > trust (with higher confidence) the headers added by the user's mail hosting > provider or the server the user logged into, or basically the last processing > machine at the hosting provider. > > Maybe Murray can comment on this, I don't recall seeing a discussion where the > A-R verifying.domain was tied to some trusted hosted domain we have confidence > in. Can the MX or MDA domains be associated with the A-R verifying the > domain?
To verify domain hierarchy might be possible, but cumbersome. Section 1.6 of the rfc says "valid use of the header field requires removing any occurrences of it that claim to be associated with the ADMD". IMHO that is the minimal requirement. I find it handy to remove /all/ existing A-R fields[*]. That way, you can tell the MUA to just trust A-R in the messages retrieved from such account. [*] Actually, the server renames them Old-Authentication-Results, so they're visible when you manually watch the headers. Best Ale -- _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
