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

[Alessandro Vesely <[e-mail]>]

Just a couple of notes, inline:

On Mon 24/Aug/2020 20:20:06 +0200 Todd Herr wrote:
> 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.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.


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


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


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


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


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


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


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


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


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