On 12/30/20 7:35 AM, Todd Herr wrote:
On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas <[email protected]
<mailto:[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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
