Re: [dmarc-ietf] Revisiting DMARC bis Ticket 66 - What It Means To Implement DMARC

[Todd Herr <[e-mail]>]

Thank you for the feedback, Ale; comments inline.

On Sat, Aug 22, 2020 at 5:06 AM Alessandro Vesely <[e-mail]> wrote:

> On Fri 21/Aug/2020 21:25:50 +0200 Todd Herr wrote:
> [snip]
>
> >
> -------------------------------------------------------------------------------------------------------------------------
> > 8 Implementations
> >
> > The characteristics of a DMARC implementation will vary for the different
> > roles in the messaging infrastructure.
> > 8.1 Domain Owner Implementations
> >
> > Section 6.5 <https://tools.ietf.org/html/rfc7489#section-6.5> describes
> > many of the provisions for implementing the DMARC mechanism as a Domain
> > Owner. This section will clarify those needed for minimal and full
> > implementations.
>
>
> I'd start by introducing the distinction between domain owner and mail
> receiver.
>
>
The distinctions already exist in RFC 7489, the original DMARC spec:

https://tools.ietf.org/html/rfc7489#section-3


> A statement should then say what is the combined minimal/ full
> implementation.
>
>
> > 8.1.2 Full Domain Owner Implementation
> >
> > Full implementation of the DMARC mechanism by a Domain Owner requires all
> > of the following characteristics:
> >
> >     -
> >
> >     Creation of the DMARC policy record in DNS which meets these
> criteria:
> >     -
> >
> >        The policy record MUST express a Requested Mail Receiver policy of
> >        “quarantine” or “reject” for the Organizational Domain and all
> sub-domains
> >        -
> >
> >        The Requested Mail Receiver policy MUST apply to a percentage of
> mail
> >        not less than 100
> >        -
>
>
> Nope.  A domain can say it has a *strict policy* when the above criteria
> are met.  Standing the principle that domains which host human users
> mailboxes must not publish a strict policy, mandating that these domains
> don't fully implement DMARC makes little sense.
>
> Note that I'm opposed to said principle, which is a limitation of DMARC.
> However, the limitation is there and we must first remove it.  Afterwards,
> perhaps, we can mandate strict policies.
>
>
I'm not clear on what you mean by "strict policy"; it's not a term I used
here.

Also worth noting is that I'm not trying to mandate anything, only
attempting to define two levels of implementation for each role - minimal
and full.


>
> >     Establishment of an address to receive aggregate reports at least
> daily;
> >     other than in exceptional circumstances such as resource exhaustion,
> the
> >     address must support receiving reports up to at least ten megabytes
> in size.
> >     -
> >
> >     Deployment of authentication technologies to ensure Identifier
> Alignment
>
>
> Isn't it clearer to say "both SPF and DKIM"?
>
>
Perhaps, but I took pains here to re-use the same verbiage that's in
section 6.5 of RFC 7489:

https://tools.ietf.org/html/rfc7489#section-6.5


>
> > 8.2 Mail Receiver Implementations
> >
> > This section will describe minimal and full implementations of the DMARC
> > mechanism for Mail Receivers.
>
>
> > 8.2.1 Minimal Mail Receiver Implementation
> >
> > Minimal implementation of the DMARC mechanism by a Mail Receiver means
> > fully implementing the provisions of Section 6.6
> > <https://tools.ietf.org/html/rfc7489#section-6.6>
>
>
> Maybe a minimal implementation could skip storing the results of DMARC
> processing.
>
>
Perhaps, but again I was re-using text from the original RFC -
https://tools.ietf.org/html/rfc7489#section-8


> >     -
> >
> >     Validation of any ARC header sets found in the message
>
>
> Nope.  DMARC has nothing to do with ARC.
>
>
Your statement is true, but I would submit that ARC has everything to do
with DMARC (and SPF, and DKIM) and attempting to mitigate the failures in
authentication that can be caused by mail transiting intermediaries.


>
> >     -
> >
> >     Enforcement of discovered policies in a manner that is consistent
> > with Section
> >     6.7 <https://tools.ietf.org/html/rfc7489#section-6.7>
>
>
> Hm...  that adds nothing to the requirements.  Section 6.7 allows
> receivers to do what they see fit.
>
>
Again, I'm not proposing to mandate any behavior here, only to define
different levels of implementation; further, I don't sense much in the way
of consensus from the group on trying to mandate behavior.


>
> >     -
> >
> >     Send aggregate reports at least daily using “mailto” URIs; such
> >     aggregate reports MUST be no larger than ten megabytes in size.
>
>
> I'd just mandate reporting.  Size is a different issue.
>
>
The ten megabytes limit is original text from section 8 -
https://tools.ietf.org/html/rfc7489#section-8 -  It seems antiquated to use
such a small size today, but I was trying not to stray too far afield of
the original text.

Limiting the size makes more sense for each mailto: address, as it should
> reflect message size limits that the corresponding MTA enforces.  See also
> ticket #53.
>
> Some domains react to the size limit by sending multiple records for the
> same period.  The sum of sizes exceeds the size of a single report, given
> the way compression works.
>
> Report size is obviously inversely proportional to frequency.  How about
> requiring the ability to send reports hourly for full implementations and
> at least daily for medium ones?
>
>
Once every 24 hours was in the original text; I wasn't present at the
creation of the original RFC, but it seems to be a cadence that most
reporters use.

-- 

*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.