Re: [dmarc-ietf] not enhanced status codes Some Proposed Language for a New pct Tag Defintion
2.6.0 really is a mystery to me. The domain under study uses p=reject and is getting 100% authenticated in the RUA reports, so it does not fit John's theory. I always get 2.6.0 from outlook.com servers and a few other destinations. So perhaps it is just their version of "OK so far, but I may block you later in the evaluation process." I would be interested if anyone else has data on extended status codes. If it seems too off-topic for the whole group, you can send to me directly. Doug On Sat, Jul 31, 2021 at 4:24 PM John Levine wrote: > It appears that Murray S. Kucherawy said: > >Indeed; I would like to understand what 2.6.0 is meant to convey. As I > >read the IANA registry entries, "2" means success but "6" means there was > a > >media type error. > > I think it's supposed to mean "I accepted your message but I wouldn't have > if I were > enforcing DMARC p=none". > > Since this would be a gift to spammers trying to probe and evade filters, > I find it > very unlikely anyone would implement it, so no. > > R's, > John > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion
Ale, I understand your concern but I don't know that it can be solved. My core objection is the partial-enforcement algorithm. I cannot believe that it would be wise for me, or any other receiver, to implement that algorithm. However, DMARCv1 was written with a presumed requirement for participating recipients to follow that algorithm. Given my expectations around actual recipient behavior, it seems unreasonable to tell domain owners to expect a different set of behaviors than what will actually occur. I do not want to mislead. During evaluation, my practice will be to treat any value other than 100 as equal to zero, because it means that the sender does not have enough confidence in his situation to be able to provide me with useful information. It does not mean that I will ignore the sender authentication failure. In the face of ambiguity, the only way to get a correct disposition is to collect more data.If I had more time, I would quarantine all unauthenticated mail until I could determine whether the sender should be authenticated by local policy or blacklisted by local policy. In practice, I quarantine some messages and let some messages through, then periodically go back and adjust my policies after reviewing actual message details. Doug Foster On Sat, Jul 31, 2021 at 5:40 AM Alessandro Vesely wrote: > On Fri 30/Jul/2021 22:06:39 +0200 Todd Herr wrote: > > Following on to the recent discussion about the pct tag, and > specifically the > > disallowing of any values other than 0 and 100, I propose the following > text > > and look forward to your comments: > > > I still dislike this limitation. I previously showed that users seem to > change > pct= with some salt. In addition, how should implementations amend their > code? > What shall a receiver do if it finds intermediate values of pct? > > I'd keep allowing intermediate values. Substitute /Possible values are as > follows:/ with /RECOMMENDED values are as follows:/. > > For case 0: > > YOUR TEXT: > 0: A request that zero percent of messages producing a DMARC > "fail" result have the specified policy applied. While this is > seemingly a non-sensical request, this value has been given > special meaning by some mailbox providers and intermediaries > when combined with "p=" values other than "none". In those > cases, in can result in changes to message handling, and/or > DMARC reporting for the domain publishing such a policy. In > some instances of altered reporting, it is possible that the > altered reports may reveal intermediaries whose handling of the > domain owners' mail could cause it to produce a DMARC result of > "fail" when it reaches its final destination. > > MY PROPOSED ALTERNATIVE: > 0: A request that messages producing a DMARC "fail" result never > have the specified policy applied. The special meaning of > this value is to have mailing lists which discriminate message > handling by author's domain policy apply From: munging > (see [Section X.Y.Z]) while final receivers still apply no > policy. > > > Best > Ale > -- > > > > > > > > > > > > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion
I'd make it a lot simpler: pct: (plain-text integer; OPTIONAL; default is 100). For the RFC5322.From domain to which the DMARC record applies, the "pct" tag describes what receivers are requested to to do with unaligned messages. This parameter does not affect the generation of DMARC reports. Possible values are as follows: 0: A request to not apply the policy, but for message forwarders to do whatever message rewriting they do that is intended to avoid sending DMARC unaligned mail. 100: The default, a request to apply the policy as specified. Any other value: results are undefined. It makes no sense to say anything about how DMARC reports are received, they're received however they are. If there were some way to give them a free pass, whaddaya know, spam would start looking like DMARC reports. The way this is written, p=none pct=0 requests rewriting, which I don't think is wrong. It doesn't mean anything else now. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] not enhanced status codes Some Proposed Language for a New pct Tag Defintion
It appears that Murray S. Kucherawy said: >Indeed; I would like to understand what 2.6.0 is meant to convey. As I >read the IANA registry entries, "2" means success but "6" means there was a >media type error. I think it's supposed to mean "I accepted your message but I wouldn't have if I were enforcing DMARC p=none". Since this would be a gift to spammers trying to probe and evade filters, I find it very unlikely anyone would implement it, so no. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion
On Fri, Jul 30, 2021 at 5:13 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Unfortunately, it seems the extended status codes have very limited > deployment. When I searched my recent history, I could only find codes > 2.0.0 and 2.6.0, which communicate nothing incremental. > Indeed; I would like to understand what 2.6.0 is meant to convey. As I read the IANA registry entries, "2" means success but "6" means there was a media type error. Would it be reasonable to add language saying that we RECOMMEND that > evaluators use extended status codes, for both accepted and rejected > messages, to indicate the message authentication status? We could > highlight the codes that are particularly relevant to this need. > I'm not sure about RECOMMENDED, but reminding readers of this mechanism for providing additional information seems at least harmless to me. If we say RECOMMENDED, I'd be inclined to think we should say something about both producers of these codes and consumers of them, to encourage interoperability. There's no point in making a strong push toward generating them if nobody has any incentive to do something with them when they're observed. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion
Hello, for me this wording of pct=0 is not clear enough, why the value is necessary. Why the value is necessary can be explained by: When seeing pct=0 mail intermediaries should munge the From: header. This allows mail operators to detect problems with DMARC deployment, before strict DMARC policy is applied. Greetings Дилян On Fri, 2021-07-30 at 16:06 -0400, Todd Herr wrote: > Following on to the recent discussion about the pct tag, and > specifically the disallowing of any values other than 0 and 100, I > propose the following text and look forward to your comments: > > pct: (plain-text integer; OPTIONAL; default is 100). For the > RFC5322.From domain to which the DMARC record applies, the > "pct" > tag is the percentage of messages producing a DMARC result of > "fail" to which the Domain Owner wishes its preferred handling > policy be applied. However, this MUST NOT be applied to the > DMARC-generated reports, all of which must be sent and received > unhindered. Possible values are as follows: > > 0: A request that zero percent of messages producing a DMARC > "fail" result have the specified policy applied. While this > is > seemingly a non-sensical request, this value has been given > special meaning by some mailbox providers and intermediaries > when combined with "p=" values other than "none". In those > cases, in can result in changes to message handling, and/or > DMARC reporting for the domain publishing such a policy. In > some instances of altered reporting, it is possible that the > altered reports may reveal intermediaries whose handling of > the > domain owners' mail could cause it to produce a DMARC result > of > "fail" when it reaches its final destination. > > 100: The default, in which a request is made that every > message > that produces a DMARC "fail" result will be subject to > application of the specified policy. > > I'll check on this thread on Monday to see where things stand... > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion
On Fri 30/Jul/2021 22:06:39 +0200 Todd Herr wrote: Following on to the recent discussion about the pct tag, and specifically the disallowing of any values other than 0 and 100, I propose the following text and look forward to your comments: I still dislike this limitation. I previously showed that users seem to change pct= with some salt. In addition, how should implementations amend their code? What shall a receiver do if it finds intermediate values of pct? I'd keep allowing intermediate values. Substitute /Possible values are as follows:/ with /RECOMMENDED values are as follows:/. For case 0: YOUR TEXT: 0: A request that zero percent of messages producing a DMARC "fail" result have the specified policy applied. While this is seemingly a non-sensical request, this value has been given special meaning by some mailbox providers and intermediaries when combined with "p=" values other than "none". In those cases, in can result in changes to message handling, and/or DMARC reporting for the domain publishing such a policy. In some instances of altered reporting, it is possible that the altered reports may reveal intermediaries whose handling of the domain owners' mail could cause it to produce a DMARC result of "fail" when it reaches its final destination. MY PROPOSED ALTERNATIVE: 0: A request that messages producing a DMARC "fail" result never have the specified policy applied. The special meaning of this value is to have mailing lists which discriminate message handling by author's domain policy apply From: munging (see [Section X.Y.Z]) while final receivers still apply no policy. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
