Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Douglas Foster <[e-mail]>]

I have always assumed that p=quarantine and pct<>100 were included to
provide political cover for "Nervous Nellies" who were afraid to enable
p=reject.

As an example, suppose Nellie makes the decision enable p=quarantine and
then goes badly:

If the recipient reports reject instead of quarantine, she can say:   "They
were not supposed to review it!  They did not follow instructions!"

If the recipient reports quarantine as requested, she can say:   "They
agreed to look at it.   We can assume that they will release it to the user
after seeing that the message is innocuous, but the quarantine disposition
decision is not shown in the DMARC reports."

--

As an email gateway administrator, what I reject and what I quarantine will
be determined by my confidence level in my system's risk assessment.
 Sender request will have nothing to do with it.

Pct<>100 is pretty much similar.   A sender can specify pct=20, but that
does not mean that I am going to allow spam into my system 80% of the time
simply to make the sender happy.   Nonetheless, p=quarantine and pct=20
might allow some organizations to move away from p=none, thinking that they
are taking "baby steps", and that is a good thing.

Disabling a deployed feature is a big deal.   Leaving it deployed is a
useful ruse to promote deployment.   I favor leaving both mechanisms in
place.

Doug Foster




On Tue, Dec 1, 2020 at 6:56 PM Dave Crocker <[e-mail]> wrote:

> On 12/1/2020 3:17 PM, John R Levine wrote:
> > #39 proposes that we remove p=quarantine.  I propose we leave it in,
> > even if it
> > is not very useful, because trying to remove it would be too confusing.
>
>
> If it is confusing to remove it, it is probably confusing to keep it,
> albeit a different confusion.
>
> Since protocol specifications need to be precise in their semantics, so
> they are understood the same way by both producers and consumers, I
> suspect the issue, here, is a failure to adequately specify the meaning
> or a failure to specify something that is mutually useful and desired.
>
> So rather that be administratively expeditious for the working group
> process, I suggest this issue gets some meaningful discussion.  My email
> archive indicates it hasn't gotten any discussion at all.
>
> Just waving this through because it will be a hassle to deal with it
> invites random differences in its use, and that is death to
> interoperability.
>
>
> d/
>
> --
> Dave Crocker
> [e-mail]
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red Cross
> [e-mail]
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>