On Tue, Dec 29, 2020 at 3:01 PM Michael Thomas <m...@mtcc.com> wrote:
> > On 12/29/20 11:35 AM, Todd Herr wrote: > > None of the validation checks bothered with the p= value in the > mrochek.com DMARC policy record, because the p= value is immaterial to > the validation check. Whether DMARC passes or fails is based on whether SPF > or DKIM passes or fails with an aligned domain, full stop. > > Once the DMARC validation result is determined, then the mailbox provider or > entity performing the DMARC validation check can refer to the p= value in > determining how to dispose of the message, but it doesn't have to. It's worth > noting perhaps that Google does record message disposition in the auth-res > header, though: > > dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com > > Unless those values in parens are a MUST requirement, the dmarc=fail is > highly misleading. I haven't even seen any specification for the dmarc part > of auth res in rfc 7601, which may be part of the problem. I don't see any > normative language which would update rfc7601 in dmarc with the syntax and > semantics of the dmarc field. > We're going to have to agree to disagree here. I had no hand in writing RFC 7601 or its predecessors, but I believe DMARC is covered under "Extension Methods" in section 2.7.6 (https://tools.ietf.org/html/rfc7601#section-2.7.6) and "Email Authentication Results Names" in section 6.6 ( https://tools.ietf.org/html/rfc7601#section-6.6), which references RFC 7489 section 11.2, which in turn defines pass, fail, temperror, and permerror as it pertains to DMARC. As for the parenthetical bits, I believe they too are covered in RFC 7601 section 2.7.6: Authentication method implementers are encouraged to provide adequate information, via message header field comments if necessary, to allow an MUA developer to understand or relay ancillary details of authentication results. For example, if it might be of interest to relay what data was used to perform an evaluation, such information could be relayed as a comment in the header field, such as: Authentication-Results: example.com; foo=pass bar.baz=blob (2 of 3 tests OK) And I think in this specific case that those bits are there for the consumption of the downstream parts of the Gmail infrastructure and Gmail-developed clients (it's Gmail's MTA that's inserting the header, after all). Other mailbox providers do things slightly differently, I suspect. > At the very least this needs to be straightened out because auth-res, to > Ned's earlier point, can have consumers in the form of MUA's. > The format/contents of an auth-res header and its impact on MUA development seem to be a bit off-charter for this working group, but I'll say that it might be a heavy lift to try to get major mailbox providers who run their own highly customized MTAs to comply with any effort to fully standardize. Their interpretations of the headers that they insert are done to optimize usage with their message storage infrastructure and their web and mobile clients, the latter of which the vast majority of their mailbox holders use. I don't think they have much incentive to standardize to make things easier for an open source MUA developer, but the MUA developer can probably cover most variations relatively easily with a simple bit of if-then-else logic based on the provider. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.h...@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
