On Fri 16/Jul/2021 15:44:35 +0200 Todd Herr wrote:
On Fri, Jul 16, 2021 at 5:32 AM Alessandro Vesely wrote:
On Tue 13/Jul/2021 20:09:45 +0200 Todd Herr wrote:
On Tue, Jul 13, 2021 at 7:03 AM Douglas Foster wrote:
draft-ietf-dmarc-dmarcbis-02 instead starts with this text:
pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL;
default is 100). For the RFC5322.From domain to which the DMARC
record applies, the "pct" tag is the percentage of messages
producing a DMARC result of "fail" to which the Domain Owner
wishes its preferred handling policy be applied.
Since the concept of applying DMARC policy to messages that produce a
DMARC result of "pass" doesn't exist, it doesn't make sense to claim
that "pct" applies to the entire mailstream.>>
Why not? I'd say that a DMARC filter takes no action when dmarc=pass
(except for setting Authentication-Results: and feedback data). The
policy requests noop on pass, and it is applied indeed.>
I will continue to maintain that it makes no sense to talk about the
concept of applying DMARC policy to messages which pass DMARC validation
checks, especially in the context of the 'pct' tag.
In RFC 7489, the definitions of "quarantine" and "reject" both speak of
their application in terms of "email that fails the DMARC mechanism check".
So, for a DMARC record such as this:
_dmarc.foo.com IN TXT "v=DMARC1; p=quarantine; pct=X; rua=...."
I assert that the domain owner is requesting that X percent of the messages
that fail the DMARC mechanism check be subjected to the "quarantine"
policy.
This is a minor issue. I just observed it is not necessary to pinpoint on what
set to take the percentage. The case that results in the easier wording should
be used.
To assert that the domain owner is instead asking only that DMARC
validation checks be performed on X percent of the messages runs the very
real risk of the pct mechanism being even less useful as a ratchet,
especially when X is small, because that X% of the total mailstream might
not contain any DMARC failures.
I never meant that. The DMARC check has to performed in all cases.
It occurs to me now that something like the following is considered a valid
DMARC record, and we should probably fix that:>
_dmarc.foo.com IN TXT "v=DMARC1; p=none; pct=25; rua=...."
The fix would be to describe the 'pct' tag as only valid with p= quarantine
or reject, because "p=none, pct=X" is just a nonsensical way of writing
"p=none; pct=100", because you're going to get "none" on all failures
regardless.
I agree it's quite nonsensical, except you can have p=none; sp=reject; pct=X,
which makes sense. However, it isn't worth to spend a paragraph of
specification to declare such records invalid. It is totally obvious how to
treat such cases —it's a noop, similar to the policy to be applied on
dmarc=pass.
I found various instances of such records, which I paste at the bottom of this
message.
Next, draft-ietf-dmarc-dmarcbis-02 contains a substantial rewrite
of the Message Sampling section (now section 6.7.4) that goes to
great lengths to attempt to show that the desired pct value
really can't be counted on to be applied as asked for, and what
might actually happen could vary widely from what's desired.
I find that section excessively long and difficult. It doesn't
mention the key point that the percentage is more and more exact as
the number of (failed) messages grows. Indeed, pct=20 doesn't say
that the policy should apply to one of /the first five/ messages.>
Please suggest alternate text.
I will. I appreciate your mathematical digression, but I don't think dmarcbis
is the appropriate kind of media to publish such kind of articles.
The last paragraph of Section 6.7.4.2 seems to say that pct affects
reporting:
* "0" - A request that zero percent of messages producing a DMARC
"fail" result have the specified policy applied. While this is
seemingly a non-sensical request, this value has been given
special meaning by some mailbox providers when combined with
certain "p=" values to alter DMARC processing and/or reporting for
the domain publishing such a policy.
I'd remove "and/or reporting".
This section is an attempt to discuss the need for one to have a policy of
"p=quarantine; pct=0" to get accurate reporting from Google in the past,
and was mentioned during the last interim -
https://datatracker.ietf.org/doc/minutes-interim-2021-dmarc-01-202105270900/
Please suggest alternate text.
Hm... an attempt could be as follows:
* "0" - A request that zero percent of messages producing a DMARC
"fail" result have the specified policy applied. While this is
seemingly a non-sensical request, this value has an effect on
some mailing lists or groups who rewrite the From: header field
only if the author domain publishes a strict policy. So having
p=quarantine; pct=0 changes how mail mediators behave without
affecting the actual treatment by the final receivers.
Of course, processing is different and the resulting aggregate reports change
as a consequence. Currently there are some variations on how to operate From:
munging. There should be a section on that topic, so the above paragraph could
refer to it.
Now for p=none; pct=; many records are expired, some are still current, some
make sense, some don't.
MariaDB [mail]> SELECT domain, dmarc_rec, FROM_UNIXTIME(last_recv) AS date FROM
domain WHERE dmarc_rec RLIKE 'p=none' AND dmarc_rec RLIKE 'pct=' AND NOT dmarc_rec
RLIKE 'p=[rq]' order by date desc;
+---------------------------+------------------------------------------------+---------------------+
| domain | dmarc_rec |
date |
+---------------------------+------------------------------------------------+---------------------+
| bluehost.com | adkim=r; aspf=r; p=none; pct=10 |
2021-07-17 00:38:18 |
| mailerlite.com | adkim=r; aspf=r; p=none; pct=5 |
2021-07-16 13:47:29 |
| reverbia.it | adkim=r; aspf=r; p=none; pct=1 |
2021-07-14 11:01:12 |
| kernel.org | adkim=r; aspf=r; p=none; pct=1 |
2021-07-13 21:24:30 |
| crif.com | adkim=r; aspf=r; p=none; pct=25; fo=s |
2021-07-06 14:28:33 |
| endurance.com | adkim=r; aspf=r; p=none; pct=10 |
2021-07-04 04:56:51 |
| domain.com | adkim=r; aspf=r; p=none; pct=10 |
2021-06-29 17:47:32 |
| constantcontact.com | adkim=r; aspf=r; p=none; pct=10 |
2021-06-11 18:22:30 |
| asmallorange.com | adkim=r; aspf=r; p=none; pct=10 |
2021-06-05 11:07:19 |
| netfacil.net.br | adkim=r; aspf=r; p=none; sp=none; pct=5 |
2021-05-29 12:58:25 |
| xss.de | adkim=r; aspf=r; p=none; pct=1 |
2021-05-20 23:35:57 |
| nic.cz | adkim=s; aspf=r; p=none; sp=none; pct=5; fo=1 |
2021-05-17 14:28:01 |
| oyabasket.com | adkim=r; aspf=r; p=none; sp=none; pct=90; fo=0 |
2021-02-25 04:45:41 |
| ac-orleans-tours.fr | adkim=r; aspf=s; p=none; sp=none; pct=1; fo=0 |
2021-02-25 00:20:17 |
| forgerock.com | adkim=r; aspf=r; p=none; sp=none; pct=0 |
2021-02-24 13:22:35 |
| nw.tutto-business.it | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0 |
2021-02-14 10:39:05 |
| nw.esperienza-italia.it | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0 |
2021-02-13 12:09:45 |
| ticino.com | adkim=r; aspf=r; p=none; pct=90 |
2021-02-04 14:50:44 |
| DENIC.DE | adkim=r; aspf=r; p=none; sp=none; pct=0; fo=0 |
2021-01-26 09:58:41 |
| uclouvain.be | adkim=s; aspf=s; p=none; sp=none; pct=50; fo=1 |
2021-01-05 10:42:00 |
| vshosting.cz | adkim=r; aspf=r; p=none; pct=1 |
2020-08-11 18:05:14 |
| nw.graziepromo.com | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0 |
2020-08-04 09:09:04 |
| xyonet.com | adkim=r; aspf=r; p=none; pct=5; fo=0:1:d:s |
2020-07-30 22:57:33 |
| anandbus.net | adkim=r; aspf=r; p=none; sp=none; pct=20; fo=0 |
2020-06-10 23:59:42 |
| windstream.com | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=1 |
2020-04-27 15:13:16 |
| ipage.com | adkim=r; aspf=r; p=none; pct=10 |
2020-03-30 11:16:28 |
| packlink.com | adkim=r; aspf=r; p=none; pct=60 |
2020-03-27 16:02:53 |
| hostgator.com | adkim=r; aspf=r; p=none; pct=10 |
2020-02-10 06:04:43 |
| pasteur-cayenne.fr | adkim=r; aspf=r; p=none; sp=none; pct=5 |
2019-12-27 04:27:44 |
| nw.mailzop.com | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0 |
2019-12-22 16:04:05 |
| mediacombb.net | adkim=r; aspf=r; p=none; sp=none; pct=0; fo=1 |
2019-12-15 04:42:23 |
| nw.kisend.com | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0 |
2019-11-26 18:14:11 |
| nw.mailrogue.com | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0 |
2019-11-21 20:34:34 |
| nw.mailcri.com | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0 |
2019-10-15 15:40:06 |
| nw.keesend.com | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=0 |
2019-10-13 15:57:08 |
| maersk.com | adkim=r; aspf=r; p=none; pct=1; fo=1 |
2019-07-17 09:03:42 |
| qlc.in | adkim=r; aspf=r; p=none; pct=5 |
2019-06-04 00:21:26 |
| iran.ir | adkim=r; aspf=r; p=none; pct=50; fo=1 |
2019-02-12 09:29:27 |
| 0086.info | adkim=r; aspf=r; p=none; pct=5; fo=1 |
2019-02-03 17:30:23 |
| olivet.edu | adkim=r; aspf=r; p=none; pct=5; fo=1 |
2019-02-01 19:17:07 |
| news.packlink.it | adkim=r; aspf=r; p=none; pct=60 |
2018-08-01 11:53:01 |
| ucdavis.edu | adkim=r; aspf=r; p=none; sp=none; pct=5; fo=1 |
2018-04-29 04:19:01 |
| anchus.com.ar | adkim=r; aspf=r; p=none; sp=none; pct=1 |
2018-04-10 19:19:24 |
| junkemailfilter.com | adkim=r; aspf=r; p=none; sp=none; pct=0 |
2018-02-02 21:47:05 |
| bnl.gov | adkim=r; aspf=r; p=none; pct=10 |
2018-01-24 02:12:25 |
| aqa.org.uk | adkim=r; aspf=r; p=none; sp=none; pct=10 |
2018-01-24 01:01:06 |
| explorartdigital.com | adkim=r; aspf=r; p=none; sp=none; pct=1 |
2018-01-16 17:13:23 |
| mail1.datongcloud.com | adkim=r; aspf=r; p=none; pct=50 |
2018-01-12 18:25:53 |
| hulusungaitengahkab.go.id | adkim=r; aspf=r; p=none; pct=20 |
2018-01-01 04:08:33 |
| demmarkita2.com | adkim=r; aspf=r; p=none; pct=20 |
2017-10-18 13:56:23 |
| opentext.com | adkim=r; aspf=r; p=none; sp=none; pct=10; fo=s |
2017-09-28 22:43:18 |
| eu.org | adkim=r; aspf=r; p=none; sp=none; pct=10 |
2017-07-25 19:42:09 |
| ramosmirkin.com | adkim=r; aspf=r; p=none; sp=none; pct=1 |
2017-07-23 12:00:18 |
| macsales.com | adkim=r; aspf=r; p=none; pct=0 |
2017-06-22 19:46:57 |
| opayq.com | adkim=r; aspf=r; p=none; pct=0 |
2017-06-09 12:44:37 |
| mchsi.com | adkim=r; aspf=r; p=none; sp=none; pct=0; fo=1 |
2017-01-01 18:58:58 |
| lqfconos.com | adkim=r; aspf=r; p=none; sp=none; pct=1 |
2016-10-24 20:00:38 |
| unimelb.edu.au | adkim=r; aspf=r; p=none; sp=none; pct=10 |
2016-02-28 02:36:47 |
| waltermoreno.com | adkim=r; aspf=r; p=none; sp=none; pct=1 |
2015-05-02 22:09:08 |
+---------------------------+------------------------------------------------+---------------------+
59 rows in set (0.088 sec)
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
