Hello,
Is the period for abstentions on posting now over?
The designers of DMARC anticipated this fear, and built several different
transitional states, or ratchets, into the protocol, including:
- "quarantine" as a value for "p=" (
https://trac.ietf.org/trac/dmarc/ticket/39)
After reading several opinions on this, I do not think that
“quarantine” means a transitional state between “reject” and “none”,
according to the majority. The distinct “quarantine” and “reject”
options exist, solely because the SMTP protocol does permit this
distinction. Both options protect the domain equally good. Both
options are only hints from the domain owner, which hints can be
altered by the recipient (the recipient can handle all “reject” as
“quarantine” and all “quarantine” as “reject”).
I have not read the recent drafts. In case the drafts do not discuss,
while reject is better than quarantine, it is not better: reject and
quarantine are equally good final states.
There are two exceptions:
• Reject allows the sender of emails (the administrator/postmaster) to
get an (immediate) notification, when the DKIM+DMARC implementations
on sender and receiver disagree, quarantine does not allow such
feedback. The administrator can take actions to fix the
implementation, based on the feedback for a concrete message.
• Reject allows the sender (the user, mailbox owner) to look for
alternative means to contact the recipient, once the mail is
immediately returned. When quarantine is used, a DMARC/DKIM
implementations on an end has errors, or transitional DNS problems
happen, and the recipient does not (regularly) check its spam folder,
the mail is essentially lost and nobody is notified.
With the above exceptions in mind, that have negative impact only when
quarantine is used, it is biased to state, that quarantine is a
transitional state between reject and none.
Past experience showed, that reducing the ratches, by striking
quarantine out, leads to endless mail threads, which nobody can follow.
I think it is realistic to mention the above two exceptions.
In fact, as somebody mentioned two years ago, the DMARC wording
suggests that reject is stronger than quarantine. The wording at
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-02#section-6.7.4.1 (pct fallback to quarantine from reject) does currently support this concept. As far as I remember, there was consensus to remove this text. (pct=10; p=reject shall fall back to p=none, not to p=quarantine). If the reasoning on why shall QUARANTINE be kept, is taken into account (=because SMTP allows this variant), the reasoning in no way explains, why is quarantine a transitional
state.
My opinion is, that the current editing process does improve the
situation, but DMARC/DKIM will remain complex topics. Even if a
misunderstanding on why is reject stronger (better) protection than
quarantine remains, there will still be improvements in other areas.
The “extreme position” below is not extreme enough: since SPF is
pointless in indirect mail loops, SPF records shall never be touched
when dealing with DMARC. I agree with the extreme position, but I do
not believe there will be consensus on it.
Greetings
Дилян
----- Message from Todd Herr <[email protected]>
---------
Date: Tue, 6 Jul 2021 08:45:35 -0400
From: Todd Herr <[email protected]>
Subject: [dmarc-ietf] Priming the Pump for Discussion - Ratchets
To: IETF DMARC WG <[email protected]>
Greetings.
The theoretical goal of any domain owner that publishes a DMARC record is
to transition from an initial policy of p=none to a final one of p=reject,
because it is only at p=reject that DMARC's intended purpose of preventing
same-domain spoofing can be fully realized.
Many domain owners see the transition from p=none to p=reject as a black
box, in that they believe they have no way of knowing what the full impact
of such a change might have on their mail, and they fear irreparable harm
to their mail if they make a mistake.
The designers of DMARC anticipated this fear, and built several different
transitional states, or ratchets, into the protocol, including:
- The "pct" tag (https://trac.ietf.org/trac/dmarc/ticket/47)
- The "sp" tag (https://trac.ietf.org/trac/dmarc/ticket/48)
- "quarantine" as a value for "p=" (
https://trac.ietf.org/trac/dmarc/ticket/39)
All of these are designed to allow the domain owner to request that some,
but not all, of its mail be held to stricter authentication standards so
that the domain owner can dip a toe in the water before jumping in.
The ratchets have introduced some problems, though:
- The 'pct' tag doesn't exactly work like it's intended to, and really
can't because of the nature of mail flow, unless there is a high volume of
failed authentication for the domain in question. (There is a much longer
discussion of this in section 6.7.4, Message Sampling, of
draft-ietf-dmarc-dmarcbis-02.)
- Some domain owners have taken a "more is more" approach to ratchets,
figuring if one is good, all are better, resulting in needlessly
complicated policy records
The purpose of this email is to get folks thinking about possibly
simplifying the ratchet mechanisms, perhaps boiling them down into one.
This thinking and on-list discussion on this topic would serve as a
precursor to further face-to-face discussion at the next interim working
group meeting.
I'll start the discussion by taking an extreme position...
Ratchet mechanisms don't help in any way that a short TTL on your DMARC
record won't help, and in fact you need the short TTL on your record
anyway, because if you're trying a ratchet mechanism and find it's too
much, you still gotta update DNS to roll it back.
Getting to p=reject isn't a difficult undertaking, at least from a
technical standpoint. Enumerate all your mail streams, ensure that they're
authenticating properly, and boom, you're done. The proper tools for doing
that are p=none, a rua tag pointed at a mailbox that is parsed by automated
means, active daily monitoring of the data consumed in those aggregate
reports (so that mail streams can be enumerated and authentication problems
addressed), and time. Time is the big one here, because sufficient time
must elapse to ensure that all of your legitimate mail streams are
exercised and reported upon, and that can take many months in large
organizations or at companies that are in the business of seasonal email
sending.
The big challenge to fixing authentication issues, especially in large
organizations, is usually in just finding who owns the host/process that's
generating that unauthenticated mail. That can add time to the process, but
once you've enumerated them all, updated your SPF record and/or made sure
they're all properly DKIM signing, you can skip right from p=none to
p=reject.
I look forward to lively conversation...
--
*Todd Herr* | Technical Director, Standards and Ecosystem
*e:* [email protected]
*m:* 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.
----- End message from Todd Herr
<[email protected]> -----
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
