On Sun 07/Jun/2020 23:23:16 +0200 Seth Blank wrote: > https://trac.ietf.org/trac/dmarc/ticket/51 > > In a DMARC aggregate report, a record with a disposition of "none" is > ambiguous, as a disposition of "none" at p=none means a different thing (that > no action was taken on the message) than a disposition of "none" if the DMARC > policy is reject or quarantine (the message passed an aligned authentication > check of either SPF or DKIM, and was therefore not subject to policy). > > It is desirable to have logically distinct disposition responses, and if so, > what should be reported in the latter case? As a straw man, "pass" instead of > "none"?
The current spec, RFC 7489, does not dwell too much upon message disposition, but it is clear enough. IIRC, some ambiguity was intentional, letting "none" mean that delivery was not altered, which is not the same as telling the sender whether the corresponding messages did it to respective mailboxes or not. The report producer may be reluctant to disclose that detail, and/or further filtering decisions can be made downstream —even by the MUA— without informing DMARC agents. All in all, the current enumeration DispositionType looks fine to me, although the comment in Appendix C should clarify that it is used both for published and for evaluated policies. Personally, I do write dmarc=pass in the Authentication-Results header fields only when the "pass" comes after a strict policy. This is a per-message datum which may be worth highlighting in the UI. However, I don't think aggregate reports would be clearer by distinguishing such cases. They are not usually read by human eyes, and software can easily deduce that value by comparing with policy_published. The margin of error is limited to the case of single reports generated for periods during which the published DMARC policy changed. Yet, such events seem to be less likely than the possibility of reports erroneously reporting "pass" even when the policy published was steadily "none". Best Ale -- _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
