Hello Alessandro,

abolishing policy quarantine means with p=reject that for failed messages there 
should be some penalty and the receiving
site decides on the form of the penalty, e.g. quarantine or reject.

In fact I see the DMARC specification updated to use consistently some neutral 
word, like penalty or punishment attached
to p=reject, once p=quarantine is abolished.  This word is then dissected into 
“quarantine or reject” at the place where
it elaborates on the possible penalties, or how to do reject right.

The penalty could be implemented with reply
550 Message failed DMARC validation and was delivered in the Junk folder of the 
recipient

This form has the advantage over either quarantine or reject, that for lost 
messages, the sender can call the recipient
and the recipient can dig for the message.  So the message does not have to be 
resent and no surprizes happen.  I do not
see how could this reply mess anything, except in the cases where the sender 
does not speak English.

> OTOH, quarantine lets one forget about delivery, perhaps with a backhanded
> thought of recipients rummaging through their spam folders in search of a
> missing message.  That style seems to me to better suit ESPs, whose duty is
> rather to have a lot of mails sent than to make sure that each message is
> acknowledged, albeit they try and maximize the ratio.
> 
> IMHO, by abolishing quarantine, we make the protocol less flexible than it is.

If an ESP wants to forget about delivery, the ESP likely does not care whether 
it has implemented DMARC correctly and
then it does not need quarantine mode.

The penalty is applied to messages that are either sent by spammers or by the 
domain owner.  If messages are from
spammers, for the domain owner it is irrelevant, what kind of penalty is 
applied, but for users doing reject means
having to scan less messages in the Junk mailbox.

If messages are from the domain owner and fail DKIM/DMARC validation, the only 
way to fix DKIM/DMARC is to use policy
reject.  There is no other way to find out which messages fail DKIM/DMARC, as 
single message faiulure reports are rarely
sent, and without knowing which messages fail DMARC fixing the problem is 
unnecessary complicated.

So here, p=quarantine is in fact an option for providers, who do not care, 
whether they have implemented DMARC
correctly.

All that said:

• Is there a consensus on abolishing policy quarantine?
• If policy quarantine will be kept, will the none>quarantine>reject order be 
abolished, meaning “quarantine” will not
be handled as softer variant of “reject”?  Meaning with p=reject; pct=30 
messages are either delivered or rejected, but
the specification does state anything about quaratining 70% of the failed 
messages.

The first argument in favour of keeping policy quarantine was exactly this 
order (quarantine is a softer variant of
reject and before deploying reject one has to exercise with quarantine).

Regards
  Дилян


On Fri, 2019-07-26 at 16:30 +0200, Alessandro Vesely wrote:
> On Thu 25/Jul/2019 14:53:55 +0200 Steve Atkins wrote:
> > > On Jul 25, 2019, at 12:06 AM, Murray S. Kucherawy <superu...@gmail.com> 
> > > wrote:
> > > 
> > > On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins <st...@wordtothewise.com> 
> > > wrote:
> > > > It's interesting that the industry has decided to interpret "p=reject; 
> > > > pct=0" the way we intended "p=quarantine; pct=100".
> > > 
> > > It's semi-explicitly defined that way in the RFC, isn't it?
> > > 
> > > If so, we should fix it because (a) I don't think that's how we intended 
> > > it, and (b) in any case, nothing in there should be only semi-explicit.
> > 
> > rfc 7489 6.6.4
> > 
> > "If email is subject to the DMARC policy of "reject", the Mail
> >    Receiver SHOULD reject the message (see  Section 10.3).  If the email
> >    is not subject to the "reject" policy (due to the "pct" tag), the
> >    Mail Receiver SHOULD treat the email as though the "quarantine"
> >    policy applies.  This behavior allows Domain Owners to experiment
> >    with progressively stronger policies without relaxing existing
> >    policy."
> > 
> > It's pretty clear and well-defined; the case we're talking about, 
> > "p=reject; pct=0", is
> > just a special case of this general rule.
> > 
> > All emails will not be subject to the "reject" policy due to the pct=0 tag, 
> > so the mail
> > receiver should treat all emails as though the policy "quarantine" applies 
> > (which
> > is the same as "p=quarantine; pct=100").
> 
> I, for one, had missed that point.  Thanks for clarifying it.
> 
> It seems to mean that the resulting steps are, for example:
> 
> 
> "p=quarantine; pct=0"  (check From: rewriting)
> "p=quarantine; pct=10" (some messages go to the spam folder)
> "p=quarantine; pct=20"
> ....
> "p=quarantine; pct=100"
> "p=reject; pct=0"      (same as the previous step)
> "p=reject; pct=10"     (some messages bounce back)
> "p=reject; pct=20"
> ....
> 
> 
> Is that what we want to suggest?  In that case, we should be clearer.  Perhaps
> by adding an example in a new appendix.  However, I hardly see the above
> sequence as progressive.
> 
> I had always considered quarantine and reject to be two more or less similar
> alternatives.  Each has its merits and shortcomings, and can be chosen
> according to a sender's needs.
> 
> An advantage of reject is that one gets NDNs, which are much more universally
> adopted than failure reports.  Perhaps a bank or similar transactional sender
> would rather prefer reject, because they can timely resend bounced 
> transactions
> or notices thereof in order to have their duties accomplished.
> 
> OTOH, quarantine lets one forget about delivery, perhaps with a backhanded
> thought of recipients rummaging through their spam folders in search of a
> missing message.  That style seems to me to better suit ESPs, whose duty is
> rather to have a lot of mails sent than to make sure that each message is
> acknowledged, albeit they try and maximize the ratio.
> 
> IMHO, by abolishing quarantine, we make the protocol less flexible than it is.
> 
> 
> Best
> Ale

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to