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 <[email protected]> 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
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
