Are there any other comments on ticket 51? The report contains a disposition field where the result "none" has two different semantic meanings. Should this be clarified?
Seth, as Chair On Mon, Jun 8, 2020 at 1:24 AM Alessandro Vesely <[email protected]> wrote: > 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 > -- *Seth Blank* | VP, Standards and New Technologies *e:* [email protected] *p:* 415.273.8818 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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
