Doug, please keep your arguments focused on the technical merits of the matter, and do not make dismissive comments about users and their motivations. Those you refer to as nervous nellies are the domain owners who this protocol is designed for, many of whom are legitimately worried about blocking good mail along with bad, especially in complicated environments. We cannot dismiss a large class of users as being silly just because their operational experience or business needs are different than our own.
Seth, as Chair On Tue, Dec 1, 2020 at 4:16 PM Douglas Foster < [email protected]> wrote: > 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 > -- *Seth Blank* | VP, Standards and New Technologies *e:* [email protected] *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
