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

From: Todd Herr <[email-masked]>
Date: Fri, 21 Aug 2020 15:25:50 -0400

https://trac.ietf.org/trac/dmarc/ticket/66

When this issue was first raised on the list back in June, it seemed that
consensus might've landed on the idea that this should be written up in a
separate BCP, rather than be part of the DMARC bis effort itself. I'm
concerned, however, that there might not be enough there there to warrant a
separate BCP, and to that end I've taken a stab at modifying the base DMARC
document, specifically Section 8, Implementation, as follows:

-------------------------------------------------------------------------------------------------------------------------
8 <https://tools.ietf.org/html/rfc7489#section-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.
8.1.1 Minimal Domain Owner Implementation

The only action required for minimal implementation of the DMARC mechanism
by a Domain Owner is the creation of the DMARC policy record in DNS.
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
      -

   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

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>
8.2.2 Full Mail Receiver Implementation

Full implementation of the DMARC mechanism by a Mail Receiver is defined by
the following characteristics:

   -

   Fully implementing the provisions of Section 6.6
   <https://tools.ietf.org/html/rfc7489#section-6.6>
   -

   Validation of any ARC header sets found in the message
   -

   Enforcement of discovered policies in a manner that is consistent
with Section
   6.7 <https://tools.ietf.org/html/rfc7489#section-6.7>
   -

   Send aggregate reports at least daily using “mailto” URIs; such
   aggregate reports MUST be no larger than ten megabytes in size.

8.3 Report Receiver Implementations

The following implementations are defined for operators that receive
reports about messages related to another operator. Implementations for
Domain Owners that receive reports about their own messages are described
in Section 8.1.
8.3.1 Full Report Receiver Implementation

Full implementation of the DMARC mechanism by a Report Receiver means
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.
8.4 Intermediary Implementations

The term “Intermediary” is meant to encompass Mediators, Relays, and
Gateways as defined in [EMAIL-ARCH
<https://tools.ietf.org/html/rfc7489#ref-EMAIL-ARCH>]. This section will
describe minimal and full implementations for Intermediaries.
8.4.1 Minimal Intermediary Implementation

Minimal implementation of the DMARC mechanism by an Intermediary means
fully implementing the provisions of Section 6.6
<https://tools.ietf.org/html/rfc7489#section-6.6>
8.4.2 Full Intermediary Implementation

Full implementation of the DMARC mechanism by an Intermediary is defined by
the following characteristics:

   -

   Fully implementing the provisions of Section 6.6
   <https://tools.ietf.org/html/rfc7489#section-6.6>
   -

   Attaching a complete and valid ARC Set of headers to the message
   -

   Enforcement of discovered policies in a manner that is consistent
with Section
   6.7 <https://tools.ietf.org/html/rfc7489#section-6.7>
   -

   Send aggregate reports at least daily using “mailto” URIs; such
   aggregate reports MUST be no larger than ten megabytes in size

-------------------------------------------------------------------------------------------------------------------------
Thank you for reading, and I look forward to any and all comments and
discussion.

-- 

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

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 22 Aug 2020 11:06:35 +0200

> https://trac.ietf.org/trac/dmarc/ticket/66

It seems to me it is a bit too early to consider this issue.

> document, specifically Section 8, Implementation, as follows:

I'm not yet clear about how many documents will the WG end up with.

> 8 Implementations

I'd start by introducing the distinction between domain owner and mail receiver.

A statement should then say what is the combined minimal/ full implementation.

> by a Domain Owner is the creation of the DMARC policy record in DNS.

Ok.

>        The Requested Mail Receiver policy MUST apply to a percentage of mail

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.

>     Deployment of authentication technologies to ensure Identifier Alignment

Isn't it clearer to say "both SPF and DKIM"?

> <https://tools.ietf.org/html/rfc7489#section-6.6>

Maybe a minimal implementation could skip storing the results of DMARC processing.

>     <https://tools.ietf.org/html/rfc7489#section-6.6>

Ok.

>     Validation of any ARC header sets found in the message

Nope.  DMARC has nothing to do with ARC.

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

>     aggregate reports MUST be no larger than ten megabytes in size.

I'd just mandate reporting.  Size is a different issue.

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?

> address must support receiving reports up to at least ten megabytes in size..

Ok.

> 8.4 Intermediary Implementations

I don't comment on this section, as we haven't established much about intermediaries, yet.

Unless some intermediator-specific behavior is going to be defined, an intermediary implementation should be just the same as any other one.

BTW, I'm not receiving reports from ietf.org.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Mon, 24 Aug 2020 14:20:06 -0400

Thank you for the feedback, Ale; comments inline.

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

> [snip]
The distinctions already exist in RFC 7489, the original DMARC spec:

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

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

> 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

> Maybe a minimal implementation could skip storing the results of DMARC
Perhaps, but again I was re-using text from the original RFC -
https://tools.ietf.org/html/rfc7489#section-8

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

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

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

--

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 25 Aug 2020 10:43:55 +0200

Just a couple of notes, inline:

> I'm not clear on what you mean by "strict policy"; it's not a term I used

I was proposing that term, as an alternative to "domain X fully 
implements DMARC" —which can hardly be a synonym of "domain X deploys 
a strict DMARC policy".

> attempting to define two levels of implementation for each role - minimal

Got it.  Still, to require a strict policy in order to enable a mail 
site to boast full DMARC compliance makes little sense nowadays, 
especially since we deprecate Yahoo, AOL, et al. for having done so...

> authentication that can be caused by mail transiting intermediaries.

The difference is DMARC is deterministic, in the sense that a receiver 
can mechanically operate according to the spec.  ARC, reputation 
sites, and other external sources of information are very useful but 
have "batteries not included".

> such a small size today, but I was trying not to stray too far afield of

Uh, I hadn't noticed it.  SMTP mandates a minimum of 64K only.  In 
Italy, we have a legal minimum of 30Mb[*], Gmail can receive up to 
50Mb[†], while others still suggest a limit of 10Mb[‡].  Looking 
around, I see values ranging from 150Mb to 40Mb:

250-DM3NAM06FT012.mail.protection.outlook.com Hello [5.170.68.61]
250-SIZE 157286400

250-mx.google.com at your service, [5.170.68.61]
250-SIZE 157286400

250-BN8NAM12FT041.mail.protection.outlook.com Hello [5.170.68.61]
250-SIZE 157286400

250-ietfa.amsl.com
250-PIPELINING
250-SIZE 67108864

250-BN8NAM11FT050.mail.protection.outlook.com Hello [5.170.68.61]
250-SIZE 49283072

250-mtaproxy523.free.mail.gq1.yahoo.com
250-PIPELINING
250-SIZE 41943040

250-us-app.us.dmarcian.com
250-PIPELINING
250-SIZE 40960000

[*] https://tools.ietf.org/html/rfc6109#section-3.1.1
[†] https://support.google.com/a/answer/1366776?hl=en
[‡] 
https://support.microsoft.com/en-us/office/send-large-files-with-outlook-8c698842-b462-4a4c-8d53-5c5dd04f77ef

> creation of the original RFC, but it seems to be a cadence that most

This topic deserves more discussion.  The spec doesn't help much for 
developing a way to negotiate values of ri= between the consumer and 
the producer of aggregate reports.

Best
Ale
--