Re: [dmarc-ietf] auth-res vs. dmarc

[Todd Herr <[e-mail]>]

On Tue, Dec 29, 2020 at 12:48 PM Michael Thomas <[e-mail]> wrote:

>
> On 12/29/20 9:18 AM, Todd Herr wrote:
>
>
> The intent of the p= value is for the domain owner to communicate a
> request for message handling by the entity evaluation the DMARC results; a
> policy of p=none means "please treat this message the same as you would
> have if you hadn't performed a DMARC check on it, regardless of the result
> obtained from the check".
>
> Right, but that is not what Google at least is doing  in their Auth-res.
> It's marking it as DMARC=fail.
>
I'm sorry, but I just don't do well with abstract concepts. Could you
please favor me with an example Authentication-Results header that's got
you vexed, so that I might understand what you're seeing?


> I think the issue is with rfc 7601 because all I see in it are some DMARC
> codepoints for IANA unless I missed something. But it could also be
> considered a fault of DMARC if there isn't normative language on what
> constitutes pass/neutral or missing/fail. Of course this can just be a
> Google bug, but it looks more likely underspecification to me.
>
> Maybe Murray can chime in here.
>

RFC 7489 contains this text in section 4.2:

   A message satisfies the DMARC checks if at least one of the supported
   authentication mechanisms:

   1.  produces a "pass" result, and

   2.  produces that result based on an identifier that is in
alignment, as defined in Section 3
<https://tools.ietf.org/html/rfc7489#section-3>.


> My feeling is that failure should be reserved only in the case where both
>> SPF and DKIM fail and that the p= > none. What I'd *really* like from a UI
>> standpoint is the p= value passed along as well so I can decide to decorate
>> reject differently from quarantine and none.
>>
>  A typical domain owner with a non-trivial email infrastructure and an
> eventual goal of getting to p=reject will start with p=none, and will
> consume aggregate and failure reports, and will use the data in those
> reports to address any shortcomings in their authentication practices.
> Aggregate reports containing DMARC failure verdicts will be quite useful to
> the domain owner, to ferret out those cases where Mike in Marketing has
> contracted with a third party to send mail on behalf of the domain, or
> where Ellen the Engineer has a server running off the side of her desk,
> sending reports to $ARBITRARY_MAILBOXES and ensure that such mailstreams
> are properly authenticated before updating the DMARC policy to p=quarantine
> or p=reject. It's not uncommon for some domains to be at p=none for months,
> perhaps twelve or more, depending on their mailing practices and cadences
> before making the switch. Domain owners won't move to p=reject until
> they're sure that enforcement of such a policy won't have a negative impact
> on their mail flow.
>
> In the mean time, it would be nice for MUA's to be able to do their part
> with annotating mail. DMARC=fail is really unhelpful with p=none.
>
>
> I'm not sure there's any value in annotating the DMARC fail/p=none
combination. The domain owner in that case has not committed to a state
where it believes that all of its mail is properly authenticated, and so
it's possible that some percentage of legitimate mail sent by or on behalf
of the domain owner will fail.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [e-mail]
*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.