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.
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.
The second paragraph of Section 6.7.4.2 surmises that the percentage is meant
on a daily basis. From such assumption, it then infers its inexactness.
The "pct" tag is a request to take a sample of a larger population
and apply different rules to it. The population is made up of all
messages that produce DMARC "fail" results for that domain in a given
day, and the sample size is the percentage of that population
represented by the value of the "pct" tag. It is trivial to perform
this sampling to the exact number specified if the population size is
known, but the nature of email is such that the population size
cannot be known until all messages have been collected and evaluated
that day. Email traffic tends to flow in spurts, not at a constant
level throughout the day, and so a volume seen during any time slice
cannot be extrapolated across a 24 hour period. Waiting until the
end of the day to decide which messages to either quarantine or
reject goes against all best practices and exposes the mail-receiving
organization to vectors of abuse, and so we must approximate the
population and sample sizes on the fly.
It would be untroubled to consider the population to be made up of all messages
for that domain during all of the time while the given DMARC record holds. The
approximation then results from interrupting the message stream, or altering
the record, before the applied percentage reaches the exact value expressed
therein, which otherwise it will eventually meet.
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".
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
