Re: [dmarc-ietf] A.5 Issues with ADSP in Operation
On Fri, Mar 15, 2024 at 12:55 AM Alessandro Vesely wrote: > On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote: > > On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely > wrote: > >> On 12/03/2024 03:18, Neil Anuskiewicz wrote: > >> > Please remove the pct tag from the spec. > >> > >> It has been removed already, which is incompatible with current records. > >> > > > > I don't believe your assertion of incompatibility to be true, Ale. > > > > DMARCbis, like RFC 7489 before it, contains this sentence in the > > description of DMARC records: > > > > Unknown tags MUST be ignored. > > > > Any site implementing the DMARCbis spec will see "pct" as an unknown and > > ignore it. > > People having pct=n, n ≪ 100, will be in for a harsh surprise. > My impression from the previous discussions is that those users weren't getting what they expected from "pct=" anyway because of varying implementations at receivers. One could argue that the surprise has already happened. -MSK, p11g ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] A.5 Issues with ADSP in Operation
> On Mar 9, 2024, at 10:05 AM, Alessandro Vesely wrote: > > Hi, > > as ADSP is historical, perhaps we can strike A5 entirely. If not, we should > at least eliminate bullet 5: > > 5. ADSP has no support for a slow rollout, i.e., no way to configure > a percentage of email on which the Mail Receiver should apply the > policy. This is important for large-volume senders. > > (Alternatively, we could think back about pct=...?) > > If anything, DMARCBis should assist (provide guidance) with ADSP to DMARC migration considerations. There are still folks who don’t believe in DMARC and continue to have an ADSP. ADSP has two basic policies: DISCARDABLE and ALL. ALL means lways signed by anyone. DISCARDABLE means always signed by the Author Domain, DMARCbis continues to use the term “Super ADSP” in section A5. We may be beyond justifications of why DMARC replaced ADSP. Help with migration would be useful. While an ADSP DISCARD policy may translate to a DMARC p=reject, an ADSP ALL policy may not have any DMARC equivalent unless non-alignment was a defined policy (in DMARC) - I don’t there is. All the best, Hector Santos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] A.5 Issues with ADSP in Operation
On 14/03/2024 19:06, Matt V wrote: On Thu, Mar 14, 2024 at 10:55 AM Alessandro Vesely wrote: On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote: On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely wrote: On 12/03/2024 03:18, Neil Anuskiewicz wrote: Please remove the pct tag from the spec. It has been removed already, which is incompatible with current records. I don't believe your assertion of incompatibility to be true, Ale. DMARCbis, like RFC 7489 before it, contains this sentence in the description of DMARC records: Unknown tags MUST be ignored. Any site implementing the DMARCbis spec will see "pct" as an unknown and ignore it. People having pct=n, n ≪ 100, will be in for a harsh surprise. From what I understand several big mailbox providers already ignore it if it's not pct=0 or pct=100. Maybe. But new implementations will ignore pct=0 as well. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] A.5 Issues with ADSP in Operation
On Thu, Mar 14, 2024 at 10:55 AM Alessandro Vesely wrote: > On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote: > > On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely > wrote: > >> On 12/03/2024 03:18, Neil Anuskiewicz wrote: > >> > Please remove the pct tag from the spec. > >> > >> It has been removed already, which is incompatible with current records. > >> > > > > I don't believe your assertion of incompatibility to be true, Ale. > > > > DMARCbis, like RFC 7489 before it, contains this sentence in the > > description of DMARC records: > > > > Unknown tags MUST be ignored. > > > > Any site implementing the DMARCbis spec will see "pct" as an unknown and > > ignore it. > > > People having pct=n, n ≪ 100, will be in for a harsh surprise. > > >From what I understand several big mailbox providers already ignore it if it's not pct=0 or pct=100. ~ Matt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] A.5 Issues with ADSP in Operation
On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote: On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely wrote: On 12/03/2024 03:18, Neil Anuskiewicz wrote: > Please remove the pct tag from the spec. It has been removed already, which is incompatible with current records. I don't believe your assertion of incompatibility to be true, Ale. DMARCbis, like RFC 7489 before it, contains this sentence in the description of DMARC records: Unknown tags MUST be ignored. Any site implementing the DMARCbis spec will see "pct" as an unknown and ignore it. People having pct=n, n ≪ 100, will be in for a harsh surprise. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] A.5 Issues with ADSP in Operation
On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely wrote: > On 12/03/2024 03:18, Neil Anuskiewicz wrote: > > Please remove the pct tag from the spec. > > It has been removed already, which is incompatible with current records. > I don't believe your assertion of incompatibility to be true, Ale. DMARCbis, like RFC 7489 before it, contains this sentence in the description of DMARC records: Unknown tags MUST be ignored. Any site implementing the DMARCbis spec will see "pct" as an unknown and ignore it. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com Phone: 703-220-4153 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] A.5 Issues with ADSP in Operation
On 12/03/2024 03:18, Neil Anuskiewicz wrote: Please remove the pct tag from the spec. It has been removed already, which is incompatible with current records. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] A.5 Issues with ADSP in Operation
Please remove the pct tag from the spec. > On Mar 9, 2024, at 7:05 AM, Alessandro Vesely wrote: > > Hi, > > as ADSP is historical, perhaps we can strike A5 entirely. If not, we should > at least eliminate bullet 5: > > 5. ADSP has no support for a slow rollout, i.e., no way to configure > a percentage of email on which the Mail Receiver should apply the > policy. This is important for large-volume senders. > > (Alternatively, we could think back about pct=...?) > > 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] A.5 Issues with ADSP in Operation
Tim Wicinski skrev den 2024-03-10 00:48: I agree with Ale here - ADSP was moved to Historic in 2013. Appendix A.5 should be dropped, and some text in the document should mention ADSP is historic bla bla, ADSP is historic as working in spamassassin, see no reason to remove it, senders can still opt out if it does undesired things it was planned to be added to dmarc so the test could still be tested, but so far only hope for std without any code changes anywhere to support it, opendmarc does not yet do anyhing with above wished, hmm ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] A.5 Issues with ADSP in Operation
I agree with Ale here - ADSP was moved to Historic in 2013. Appendix A.5 should be dropped, and some text in the document should mention ADSP is historic On Sat, Mar 9, 2024 at 10:05 AM Alessandro Vesely wrote: > Hi, > > as ADSP is historical, perhaps we can strike A5 entirely. If not, we > should at least eliminate bullet 5: > > 5. ADSP has no support for a slow rollout, i.e., no way to configure > a percentage of email on which the Mail Receiver should apply the > policy. This is important for large-volume senders. > > (Alternatively, we could think back about pct=...?) > > 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
[dmarc-ietf] A.5 Issues with ADSP in Operation
Hi, as ADSP is historical, perhaps we can strike A5 entirely. If not, we should at least eliminate bullet 5: 5. ADSP has no support for a slow rollout, i.e., no way to configure a percentage of email on which the Mail Receiver should apply the policy. This is important for large-volume senders. (Alternatively, we could think back about pct=...?) Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
