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 <[email protected]> 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 > [email protected] > 408.329.0791 > > Volunteer, Silicon Valley Chapter > American Red Cross > [email protected] > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
