Subject: [dmarc-ietf] Abolishing DMARC policy quarantine

From: Дилян Палаузов <[email-masked]>
Date: Tue, 11 Jun 2019 21:00:51 +0000

Dear all,

when DMARC passes, there is no difference between p=reject and p=quarantine.

When DMARC fails validation, this means extra work for humans.  This work can be done by the sending or by the receiving
organization.

With p=quaratine, the sending organization (domain owner) indicates, that the extra work is supposed to be done by the
receiving organization.  So for the senders it is just cheaper (in terms of less work) to publish p=quarantine.

With p=reject, the sending organization (domain owner) indicates, that the extra work has to be performed by the sending
server, which might be the domain owner or some suspects.

However, it is ultimately up to the receiving site to decide, whether it wants to accept this extra work.  If it does
not accept the extra work, it just handles quarantine as reject.  This does not violate the DMARC specitification.

Do you have a story, why one wants to publish p=quaratnine?  What is the use case for it?  It just makes emails less
reliable, as they end as Junk and this is very similar to discarding the emails.

Imagine a mailing lists, where the recipient of an email address expands to several mailboxes on different domains.  An
incoming email fails DMARC validation before being distributed over the ML.  The domain owner for that mail origin has
published p=quarantine, this email cannot be delivered in the Junk folder of the recipient, because the mailing list
itself does not have a junk folder.

How about, deleting policy Quarantine and instead rephrasing policy Reject:

It is up to the receiving server if it rejects messages failing DMARC, or accepts and delivers them as Junk.

(This does not change the protocol, just the wording)

Regards
  Дилян

---

From: Ken O'Driscoll <[email-masked]>
Date: Wed, 12 Jun 2019 12:05:30 +0100

> when DMARC passes, there is no difference between p=reject and
[...snip...]
> However, it is ultimately up to the receiving site to decide, whether it
> wants to accept this extra work.  If it does not accept the extra work,
> it just handles quarantine as reject.  This does not violate the DMARC
> specitification.

Even in a moderately complex spam filtering engine, DMARC is just one
indicator / signal amongst many.

Who does the "extra work" is subjective. For example, a large mailbox
provider may consider support queries about missing or rejected emails as
unwanted "extra work" etc.

DMARC does not live in isolation - it's part to a greater ecosystem. 

> Do you have a story, why one wants to publish p=quaratnine?  What is the
> use case for it?  It just makes emails less reliable, as they end as Junk
> and this is very similar to discarding the emails.

There is a world of difference between requesting that a recipient flag an
incoming message as spam as opposed to asking them to discard it outright.
And that is regardless of how individual mailbox provides treat
p=quarantine.

A use case for p=quarantine is that when deploying DMARC for any reasonably
complex site, it forms part of a graduated approach (perhaps in conjunction
with pct=x) utilising aggregated reports to moving towards p=reject. 

The proactive nature of DMARC means that its deployment needs to be
properly planned with any risks mitigated as best as possible. The various
stages of p= can easily be articulated on a project plan / risk register.

And such sites that require such planning are often starting from a
position of improperly documented mail flows and inconsistently implemented
SPF/DKIM. In addition they often operate in regulated sectors and are
commonly top-heavy with risk-adverse middle management.

I accept that a small site with a simple mail flow which does not operate
in a regulated space and has thin governance could likely move straight
from p=none to p=reject without serious repercussions. Such sites are not
the majority of DMARC deployments.

DMARC changes how recipient mailbox providers treat email and therefore it
needs to be deployed in a controlled manner, p=quarantine being one
component of that. 

> Imagine a mailing lists, where the recipient of an email address expands
> to several mailboxes on different domains.  An incoming email fails DMARC
> validation before being distributed over the ML.  The domain owner for
> that mail origin has published p=quarantine, this email cannot be
> delivered in the Junk folder of the recipient, because the mailing list

DMARC was never originally intended / scoped to work with domains which
interacted with mailing lists. The 5322.from address rewriting kludge 
allows such interaction by removing future DMARC tests.

A mailing list operator can also choose to reject emails from domains which
have a DMARC record.

DMARC has no use case to offer when working with mailing lists.

> (This does not change the protocol, just the wording)

I think this is completely unwarranted for (at a minimum) the above
mentioned reasons.

Ken.

---

From: Hector Santos <[email-masked]>
Date: Wed, 12 Jun 2019 09:28:26 -0400

> (This does not change the protocol, just the wording)

I think that is how it was thought it would be handled.  Don't take 
"rejection" literally, in fact, it can be a discard concept as well. 
  This is all about local policy. A receiver has the option, based on 
Local Policy and the implementation software to offer:

   (o) Reject with 55x before DATA state
   (_) Reject with 55x after DATA state (allows for collection of payload)
   (_) Accept with 250 and Discard
   (_) Accept with 250 and Quarantine

Whether systems actually do rejections are not, this has been 
discussed and debated over the years.  But in my view, the thinking 
has evolved to a realization that dynamic rejections at SMTP are real 
which complicates DMARC with the presumption the DATA is always 
received.  My take is that early systems always accepted mail because 
of scale/bulk needs and/or their software didn't yet have dynamic 
hooking, shimming, spawning, scripting capabilities at the SMTP state 
points.  With the advent of advanced hardware, Dynamic SMTP processing 
at the state points is a relatively new capability, 10-15 years 
perhaps, where spawning filters at the state point became feasible 
with a small sacrifice in SMTP session time increases.

We even had the discussions about SMTP idle wait time and even 
explored the idea of a "Keep Alive" concepts using a heart beat reply 
code. But it was discovered, back then (10 years?), that not all SMTP 
clients would not be capable to support a kept alive concept while a 
SMTP server is processing a transaction.  In theory, a SMTP hook has 
about 5 mins to complete otherwise a SMTP client can time out.  The 5 
mins for time outs is pretty out-dated so don't be surprise to see 
SMTP servers lowering it down to a few minutes or less due to SMTP 
clients not hanging up causing scaling problems.  But we do expect the 
SMTP client to wait 5 mins. :)

-- 
HLS

---

From: Laura Atkins <[email-masked]>
Date: Wed, 12 Jun 2019 14:37:52 +0100

> On 12 Jun 2019, at 14:28, Hector Santos <hsantos=[email-masked]> wrote:
> 
> I think that is how it was thought it would be handled.  Don't take "rejection" literally, in fact, it can be a discard concept as well.  This is all about local policy. A receiver has the option, based on Local Policy and the implementation software to offer:
> 

Given that the 5322.from is crucial for DMARC, and the 5322.from is transmitted after DATA, how can you evaluate DMARC before DATA?

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog

---

From: Dotzero <[email-masked]>
Date: Wed, 12 Jun 2019 09:49:58 -0400

On Wed, Jun 12, 2019 at 9:38 AM Laura Atkins <[email-masked]>
wrote:

> "rejection" literally, in fact, it can be a discard concept as well.  This
> is all about local policy. A receiver has the option, based on Local Policy
> and the implementation software to offer:
>
> Given that the 5322.from is crucial for DMARC, and the 5322.from is
> transmitted after DATA, how can you evaluate DMARC before DATA?
>
>
You can't evaluate DMARC before DATA. On the other hand, evaluating DMARC
is not a MUST for SMTP email. It is at best a SHOULD and more likely a MAY.
Speaking as an original participant in the dmarc.org team, we recognized
that there was no way to mandate participation in the DMARC worldview and
that it would get implemented based on perceived value by both sending
domains and mailbox providers.

Michael Hammer

---

From: Hector Santos <[email-masked]>
Date: Wed, 12 Jun 2019 10:06:22 -0400

On 6/12/2019 9:37 AM, Laura Atkins wrote:
>
>> On 12 Jun 2019, at 14:28, Hector Santos
>>

When SPF is taking into account.  But yes, overall, my comment was 
more about the whole "rejection" issue whether it was with SPF or with 
the DATA payload technologies since MARID; SenderID, Domainkeys, DKIM, 
  then ADSP, now DMARC.  The "To Reject or Not Reject" question was 
always there.

With SPF and DMARC, for example, if the receiver was made aware of the 
5322.From before the DATA state, this would preempt the need to 
receive the payload in order to get reporting information or perhaps 
get DMARC overriding deposition, i.e. p=quarantine overrides SPF -ALL 
rejection.

How?

Well today, we had the PRA/SUBMITTER protocol used to pass the 
Purported Responsible Address via MAIL FROM:

    C: MAIL FROM:<return-path> SUBMITTER=pra

Many clients do use SUBMITTER. Enable it and they will pop up.  Since 
we deprecated submitter when SPF was made standard track, imto, it may 
be a good idea to explore leveraging this protocol to support DMARC at 
SMTP.

I know this is just an optimization. But I would prefer this 
optimization over the idea of accepting a potentially large payload of 
a SPF -ALL failure just to find out if there is a DMARC record because 
the operator may want to see such SPF only failures.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Wed, 12 Jun 2019 10:41:44 -0400

On 6/12/2019 9:49 AM, Dotzero wrote:
>
>     Given that the 5322.from is crucial for DMARC, and the 5322.from
>     is transmitted after DATA, how can you evaluate DMARC before DATA?
>
> You can't evaluate DMARC before DATA.

Sure you can. I explained how it can be explored today!

Right now, today, it can explored with an existing protocol just was 
recently made historic:

https://tools.ietf.org/html/rfc4405

The status change was done because this protocol was part of the 
SenderID vs SPF experiment and SenderID lost.  SPF was made a standard 
track protocol.   It does not mean we could not consider leveraging 
the exist SUBMITTER code for other purposes and its a right fit for a 
high overhead payload technology in DMARC. I will suggest it can offer 
a high optimization payoff:

   - Eliminate payload reception overhead, yet still
   - Provide DMARC reporting and disposition override capabilities.

I don't think its an "Horrible Idea."  I think its a great idea. :)

-- 
HLS

---

From: Vladimir Dubrovin <[email-masked]>
Date: Fri, 14 Jun 2019 18:08:04 +0300

p=quarantine with pct=0 is useful to test DMARC with mailing list/groups
which perform "From" rewrite based on DMARC policy. It's safe, because
it actually works like "none" but it causes From rewrites, because it's
still considered as "quarantine".

I would never recommend to use "quarantine" without pct=0, because it
can  mask serious deliverability problems.

12.06.2019 0:00, Дилян Палаузов пишет:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Dotzero <[email-masked]>
Date: Fri, 14 Jun 2019 11:42:49 -0400

> can  mask serious deliverability problems.

If the only thing they are using to check deliverability is DMARC
reporting, the person has other problems. You should be able to see whether
it passed/failed DKIM and SPF but that does not tell you whether it was
delivered to the end user (at all) or quarantined in a SPAM folder. Many if
not most receiving domains perform all sorts of other checks on incoming
mail.

Michael Hammer

Michael Hammer

---

From: Vladimir Dubrovin <[email-masked]>
Date: Fri, 14 Jun 2019 19:25:02 +0300

Nope, I mean 2 different things.

1. Why quarantine is useful (with pct=0). 

For example this mailing list ([email-masked]) performs From rewrite
(aka From munging), e.g. [email-masked] is replaced with
dubrovin=[email-masked]. It's because corp.mail.ru has a
strict DMARC policy (reject). [email-masked] is not overwritten,
because gmail.com has p=none and ietf.org only overwrites From only for
domains with "quarantine" and "reject" policies. It's quite common behavior.

If you are implementing DMARC for a new domain (let's say example.org),
you usually start with "p=none". With p=none you receive reports for
failed DMARC for different lists, like ietf.org. Before switching to
stronger policy (p=reject), you may want to know which mailing list will
still fail DMARC, and which lists perform From munging and, as a result,
do not fail DMARC. For this purpose, before switching to "p=reject" it's
useful to switch to "p=quarantine;pct=0". After this, you will only see
mailing lists without From munging in DMARC reports.

2. Why quarantine should not be used with pct different from 0

If you start enforsing strong DMARC policy with "p=reject" and you have
some previously uncatched misconfiguration (e.g. wrong envelope-from
address in some once-in-the-month mailing), you see DMARC failures  in
your logs and you can react to this failures and even re-send the
messages affected.
If you start with "p=quarantine" you have no feedback except reports,
and reports are received with a huge lag (up to 2 days) and do not
provide sufficient information to catch the exact problem and you can
not re-send the quarantined messages.

14.06.2019 18:42, Dotzero пишет:
>
>
> On Fri, Jun 14, 2019 at 11:08 AM Vladimir Dubrovin
> <dubrovin=[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
> reporting, the person has other problems. You should be able to see
> whether it passed/failed DKIM and SPF but that does not tell you
> whether it was delivered to the end user (at all) or quarantined in a
> SPAM folder. Many if not most receiving domains perform all sorts of
> other checks on incoming mail.
>
> Michael Hammer
>
> Michael Hammer
>

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Дилян Палаузов <[email-masked]>
Date: Fri, 14 Jun 2019 21:58:22 +0000

Hello Ken,

effectively I proposed handling p=reject and p=quarantine the same way.  Shall I read in your answer, that failed DMARC
validation is weighted differently in the overall spam evaluation, for p=reject and for p=quarantine?

> with pct=x) utilising aggregated reports to moving towards p=reject. 

There is no ordering between the policies.  p=quarantine is not a softer variant of p=reject, it is just different. 
Switching from Quarantine to Reject is not a graduate approach.  But if some subscribers here see it as such, perhaps
more discussions are necessary.

In the counter example for extra work, having support queries for rejected emails (p=reject) or for emails arriving
misteriosly as spam (p=quarantine) is the same amount of support, extra work.

Lets have an example for p=quaranite:
  majordomo@domain is an address where commands are sent and the software receiving the command always sends an answer,
even if the command is unclear.  An email is sent to majordomo@domain.  The sending domain has published policy
Quarantine.  This address has no spam/junk folder attached to it.  The options for an email are:
 * reject the email during the SMTP dialog
 * accept the email and let majordomo send an answer to it
 * arrange a human to decide which emails to discard (handle an imaginary Spam folder for the account).

The third option is expensive and causes delays.  The second option could send backscatters, so a caution has to be
payed when accepting an email.

After the total, complex spam evaluation, the spam filter is uncertain if the mail is spam or not.  DMARC evaluation on
its own fails.  Shall the email be rejected during the smpt dialog (handle Quarantine as Reject), shall the email be
accepted, or what do you suggest to do?

As for pct=0 on there was a discussion on [email-masked] whether From: shall be rewritten by the MLM on 25-26 Jan
2019 and the outcome is, that the behaviour is unclear (one cannot act wrong by rewriting or not RFC5822.From:).  So on
pct=0; further ellaboration is necessary.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 15 Jun 2019 12:59:13 +0200

On Fri 14/Jun/2019 18:25:02 +0200 Vladimir Dubrovin wrote:

> If you are implementing DMARC for a new domain (let's say example.org), you
> usually start with "p=none". With p=none you receive reports for failed DMARC
> for different lists, like ietf.org. Before switching to stronger policy
> (p=reject), you may want to know which mailing list will still fail DMARC, and
> which lists perform From munging and, as a result, do not fail DMARC. For this
> purpose, before switching to "p=reject" it's useful to switch to
> "p=quarantine;pct=0". After this, you will only see mailing lists without From
> munging in DMARC reports.
> 

I still don't get why "p=quarantine;pct=0" is better than "p=reject;pct=0".

Best
Ale
--

---

From: Hector Santos <[email-masked]>
Date: Sat, 15 Jun 2019 13:11:27 -0400

On 6/14/2019 5:58 PM, Дилян Палаузов wrote:
> Hello Ken,
>
> effectively I proposed handling p=reject and p=quarantine the same way.
>
> ..
>
>  majordomo@domain is an address where commands are sent and the software receiving the
>  command always sends an answer, even if the command is unclear.  An email is sent
>  to majordomo@domain.  The sending domain has published policy Quarantine.  This address
>  has no spam/junk folder attached to it.  The options for an email are:

Oh I see your concern/point/proposal now.

Yes, I highlighted this basic issue in years past in regards to the 
handling semantics debates. Even with SPF,  how -ALL (FAIL) was 
interpreted and handled was questioned. Some believed a -ALL FAIL 
policy is more like a quarantine because "no one actually rejects."

But overall, this would be an implementation consideration, not a 
protocol design consideration. The protocol is correct to have a 
handling semantics describing both ideas - reject and quarantine.

All we can do is highlight the existence of backend mail storage 
designs and legacy MUA protocol(s) that can not handle a quarantine 
safely. So at best, you can basically highlight the security design 
concerns and possible requirements to implement a quarantine concept.

There is much mail design history and evolution to consider. The 
concept of quarantine came with the integrated mail design premise that:

- The backend offers user folders or separate mail streams for normal 
in-box mail and quarantine, spam, junk mail separations. While this is 
common today for ESPs, this was not always the case for all backend 
designs.  It was often proprietary in nature.  No standard here unless 
we assume everyone using an "Microsoft Exchange" (MAPI) concept or 
IMAP which is not reality. This coincides with the premise,

- The broad range of online and offline MUAs all support the 
multi-folders provided by the backend.  This is again not reality and 
not always the case.

I'll give you a perfect example -- POP3.

POP3 is a single mail stream pick up protocol standard. So for a 
backend that provides POP3 service available to its customers and for 
the user using MUA with POP3 support, the backend POP3 server MUST NOT 
merge any suspicious, spam, junk or quarantine mail with the user's 
normal in-box mail pick up stream.

While an advanced POP3 backend server can emulate a single stream 
consolidation of multi-user folders, it would a major security loop 
hole to expose POP3 users to quarantined mail merged into the user's 
pop3 mail stream.  For this to work securely, this advanced POP3 
server must assume the MUAs are advanced enough or users are advanced 
enough to write MUA scripts that will separate the single pop3 stream 
into spam, junk and quarantine folders again.

All we can do is highlight how "rejects" can be interpreted 
differently.  After much discussion with SPF, while it didn't provide 
an specific example using POP3, it was generically described under 
Local Policy Considerations:

    https://tools.ietf.org/html/rfc7208#appendix-G.2

It should also be highlighted for DMARC-bis, if not already.

-- 
HLS

---

From: Дилян Палаузов <[email-masked]>
Date: Sat, 15 Jun 2019 20:25:50 +0000

Hello,

p=reject; pct=0 is equivalent to p=quarantine; pct=0.

The rest of this email is about (against) handling p=reject and p=quarantine differently.  Namely, where a server
rejects on p=reject and “quarantines” on p=quarantine.

There are more examples, all under the category p=quarantine, where the spam filter does not think a message is spam and
DMARC fails (e.g. missing DKIM-Signature):

— an autoresponder.  The incoming email will be delivered as non-spam, as the spam filter does not classify the email as
spam.  Would you suppress the autorespond (out-of-office/vacation) message, or will you take the risk to send bad
backscatters, risking lowering your IP reputation.  Is it up to the domain owner of the original message decide on you
sending backscatters, by publishing slightly different dmarc policies?  If you handle quarantine as reject there is no
such risk of getting bad IP reputation (under these concrete conditions).  If no auto-responder is sent and the mail is
not classified as spam, the user will rely on the fact, that an autoresponder was sent… big fuzz.

— an 1:1 alias to a different server.  If your server thinks the email is not spam, but the server to which the alias is
redirected thinks the message is spam, or if the user marks it as spam, your IP reputation gets worse.  If you handle
quarantine as reject there is no such risk.

— a MLM (1:many alias), where anybody can send messages - same problem as above, just bigger damage.

p=reject and p=quarantine both communicate, that all messages from a domain must have aligned, valid dkim signature or
aligned, valid spf result and that for messages from the domain failing DMARC, there must be some penalty.

How many distinct penalty levels does a sending domain owner need?

One, or more than one?  Are two penalty levels enough?  Is there justification for two penalty levels?  Can the same 
justification be used to introduce a third penalty level?  What does the domain owner/sending domain want do
communicate, by using the first, second, or third penalty level?

Currently the decisions on handling quarantine/reject in different ways are taken by:
* domain owners, who own a domain
* spammers, who use the domain of the domain owner, and let's say are distinct from the domain owners
* mailbox operators

Not taken into account are the users.  Why shall a user want to have more messages in its spam folder (assuming that the
quarantined message was at the end classified as spam and the email operator handles Reject and Quarantine differently)
versus handling p=quarantine as p=reject and having less Spam to pay attention for?

About the costs, Quarantine meaning neither deliver, not reject, but something different, can be implemented in this
way: the operator does not deliver the emails failing DMARC for a domain with p=querantine to the users, but arranges
staff, to decide what to do.  The costs for that staff, are the extra costs for having distinct handling of
Reject/Quarantine.  If there is no such staff, and the decisions are taken by the users, then the costs are the same,
these just are shifted to the users.

Finally, while DMARC can be used to communicate that all emails from a domain must PASS DMARC rules, why there is a need
to communicate what to do with emails that fail DMARC from: the domain?  The DMARC specification can be simplified, by
leaving the hanlding of such emails ultimately up to the receiving host and then there is no need to iterate the options
at protocol level for the sending domain. (The option, that all emails from a domain must have aligned DKIM signatures,
but it is up to the recipient what to do with messages without valid dkim-signature or spf result is anyway missing)j

Regards
  Дилян

---

From: Steve Atkins <[email-masked]>
Date: Sat, 15 Jun 2019 23:13:13 +0100

> On Jun 15, 2019, at 9:25 PM, Дилян Палаузов <[email-masked]> wrote:
> 
> Hello,
> 

I've not been following this thread too closely so I might be missing something, but under current
DMARC spec I don't think that's so - see section 6.6.4.

If I've missed the point ... never mind, carry on.

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Sun, 16 Jun 2019 11:42:38 -0400

On 6/15/2019 6:13 PM, Steve Atkins wrote:
>
>
>> On Jun 15, 2019, at 9:25 PM, <[email-masked]> wrote:
>>
>> Hello,
>>
> I've not been following this thread too closely so I might
> be missing something, but under current DMARC spec I don't
> think that's so - see section 6.6.4.
>

If I follow myself, I think it could be expressed as:

p=reject; pct=0; is effectively equivalent to p=quarantine; pct=100;

Given the order of mail "restriction" or "filtering" from high to low 
of reaching the user's eyeballs:

   p=reject       never accepted or accepted/discarded
   p=quarantine   accepted, imported into spam box, outside inbox
   p=none         accepted, imported into inbox

The "pct" effectively forces a fallback to the next lower applicable 
policy once the pct of failed mail has been processed:

   p=reject; pct=X;  fallback to p=quarantine
   p=quarantine; pct=X;  fallback to p=none
   p=none;  pct=X  fallback to UNDEFINED, N/A

where X can be 0 to 100.

When pct=100, which is the default, then the fallback would not apply 
since the explicit domain policy is applied to all DMARC failed 
messages. The receiver rejects mail with p=reject and quarantines mail 
with p=quarantine.

If there is an explicit pct=0, then effectively, the fallback is to be 
applied immediately, thus:

p=reject; pct=0; is effectively equivalent to p=quarantine; pct=100;

and

p=quarantine; pct=0; is effectively equivalent to p=none; pct=100;

Because of the fallback and quarantine implementation complexity and 
how failed messages can reach users, the OP is proposing to abolish 
the quarantine policy.

-- 
HLS