Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Дилян Палаузов <[e-mail]>]

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?

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

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 [e-mail] 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.

On Wed, 2019-06-12 at 12:05 +0100, Ken O'Driscoll wrote:
> 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.
> 
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc