Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Ken O'Driscoll <[e-mail]>]

On Tue, 2019-06-11 at 21:00 +0000, Дилян Палаузов wrote:
> Dear all,
> 
> when DMARC passes, there is no difference between p=reject and
> p=quarantine.
[...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
> itself does not have a junk folder.

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.

> 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)

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

Ken.