On Wed, Dec 30, 2020 at 10:41 AM Michael Thomas <[email protected]> wrote:
> > On 12/30/20 7:35 AM, Todd Herr wrote: > > On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas <[email protected]> wrote: > >> >> On 12/30/20 5:48 AM, Todd Herr wrote: >> >> >> I propose to add two new result name codes, named after the policy >>> requests: >>> >>> dmarc=quarantine, and >>> >>> dmarc=reject (of course, you only see this if the filter didn't >>> honor the request). >>> >>> >> I do not support this, because quarantine, reject, and none are not >> Authentication Results, but are instead both policy requests and >> disposition decisions. >> >> Then we should remove DMARC from auth-res altogether because it is not an >> authentication mechanism. Either we fully support DMARC in auth-res or >> remove it. This half-assed state of unlessness serves nobody. >> >> >> I disagree. DMARC has rules that determine whether or not a message is > deemed to be authenticated - did it pass SPF or DKIM and did it do so with > a domain that aligns with the RFC5322.From domain. The currently valid > states for those rules are pass, fail, temperror, and permerror. > > Policy and disposition (none, quarantine, reject) apply to decisions made > based on the authentication results; they are not states for the > authentication checks themselves. > > DMARC != Auth-res. Auth-res provides all kinds of useful information than > just pass/fail. For DMARC Auth-res should provide what the policy was at a > bare minimum. But none of this seems to have any normative language > anywhere which is a problem unto itself. DMARC in auth-res seems to be an > orphan. > > Mike > You just stated the case as to why this discussion should be ruled out of scope. " DMARC != Auth-res." and " DMARC in auth-res seems to be an orphan" This is the IETF DMARC working group, not the AUTH-RES working group. You gave the example of someone writing a crappy Thunderbird extension as a reason for the working group to change its focus. Perhaps getting the extension author to fix their extension might be a more fruitful effort. Michael Hammer
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
