Re: [dmarc-ietf] picking nits with the ABNF
On Sat, Mar 9, 2024 at 10:33 PM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> wrote:
> >> dmarc-version = "v" equals %s"DMARC1
> > I believe the "%s" should be dropped
>
> 'DMARC1' is case-sensitive in 7489.
> Either we keep the "%s" or we go back to 7489 version : "%x44 %x4d %x41
> %x52 %x43 %x31"
>
> Oh yes you are right - thanks
> I think it should be %x20-3A / %x3C-7E
> Agreed.
>
> I would also add comment about the dmarc-fo ABNF :
>
> dmarc-fo = "0" / "1" / "d" / "s" / "d:s" / "s:d"
>
> The FO paragraph (
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-general-record-format)
> explicitly states that there exist 3 kinds of failure reports :
> - DMARC failure report.
> - DKIM failure report.
> - SPF failure report.
>
>
You got me going back to 7489 and the mail archives. First it appears we
did have some discussion about this part of the ABNF
https://mailarchive.ietf.org/arch/msg/dmarc/2TT-2WiNVwCXozBz0JYRI1F1qME/
However, with the current ABNF, we could only ask for "DMARC failure
> report" or ("DKIM failure report" and/or "SPF failure report")
>
>
Shouldn't we have an ANBF rule with all the possible permutations or a more
> generic one such as :
>
> dmarc-fo = dmarc-fo-value *(":" dmarc-fo-value)
> dmarc-fo-value = "0" / "1" / "d" / "s"
>
>
The wording for FO has changed to say "0", "1" OR a colon-separated list.
Looking at the 7489 ABNF I
am wondering if someone could say "fo=0:1:d:s"
thanks
tim
> Olivier
>
> --
> *De: *"Tim Wicinski"
> *À: *"IETF DMARC WG"
> *Envoyé: *Dimanche 10 Mars 2024 01:00:33
> *Objet: *[dmarc-ietf] picking nits with the ABNF
>
> Just picking over the ABNF with my checks, some Qs
>
>
> dmarc-version = "v" equals %s"DMARC1
>
>
> I believe the "%s" should be dropped
>
> dmarc-value = %x20-3A | %x3C-7E
>
>
> I think it should be %x20-3A / %x3C-7E
>
> and now just something suggested. The comments for URI read like this
>
> ; "URI" is imported from [RFC3986]; commas
> ; (ASCII 0x2C) and exclamation points
> ; (ASCII 0x21) MUST be encoded
>
> Could they be rewritten for readability
>
> ; "URI" is imported from [RFC3986];
> ; (ASCII 0x2C) commas and
> ; (ASCII 0x21) exclamation points
> ; MUST be encoded
>
> gladly tell me i'm too obsessive
>
>
> thanks
> tim
>
>
>
> ___
> 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] picking nits with the ABNF
>> dmarc-version = "v" equals %s"DMARC1
> I believe the "%s" should be dropped
'DMARC1' is case-sensitive in 7489.
Either we keep the "%s" or we go back to 7489 version : "%x44 %x4d %x41 %x52
%x43 %x31"
> I think it should be %x20-3A / %x3C-7E
Agreed.
I would also add comment about the dmarc-fo ABNF :
dmarc-fo = "0" / "1" / "d" / "s" / "d:s" / "s:d"
The FO paragraph ( [
https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-general-record-format
|
https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-general-record-format
] ) explicitly states that there exist 3 kinds of failure reports :
- DMARC failure report.
- DKIM failure report.
- SPF failure report.
However, with the current ABNF, we could only ask for "DMARC failure report" or
("DKIM failure report" and/or "SPF failure report")
Shouldn't we have an ANBF rule with all the possible permutations or a more
generic one such as :
dmarc-fo = dmarc-fo-value *(":" dmarc-fo-value)
dmarc-fo-value = "0" / "1" / "d" / "s"
Olivier
De: "Tim Wicinski"
À: "IETF DMARC WG"
Envoyé: Dimanche 10 Mars 2024 01:00:33
Objet: [dmarc-ietf] picking nits with the ABNF
Just picking over the ABNF with my checks, some Qs
dmarc-version = "v" equals %s"DMARC1
I believe the "%s" should be dropped
BQ_BEGIN
dmarc-value = %x20-3A | %x3C-7E
BQ_END
I think it should be %x20-3A / %x3C-7E
and now just something suggested. The comments for URI read like this
; "URI" is imported from [RFC3986]; commas
; (ASCII 0x2C) and exclamation points
; (ASCII 0x21) MUST be encoded
Could they be rewritten for readability
; "URI" is imported from [RFC3986] ;
; (ASCII 0x2C) commas and
; (ASCII 0x21) exclamation points
; MUST be encoded
gladly tell me i'm too obsessive
thanks
tim
___
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] Section 9.5 DMARC Report Format Registry
Re-reading section 9.5, I think we should rewrite this to mention the registry being deprecated. I open an issue on this tim On Fri, Mar 8, 2024 at 12:00 PM Tim Wicinski wrote: > > Generally they will leave it and mark Obsolete. This should be called out > in the RFC. > (I have not looked right now). > > tim > > > On Fri, Mar 8, 2024 at 11:42 AM Murray S. Kucherawy > wrote: > >> On Fri, Mar 8, 2024 at 6:49 AM Alessandro Vesely wrote: >> >>> since we removed the rf= tag (format of failure reports), do we still >>> need to tackle the IANA registry? Since we only use one format, it >>> makes little sense. However, the registry actually exists. Is it >>> possible to delete or obsolete it, or does it have to stay there as a >>> relict for ever? >>> >> >> I'm guessing it's possible for us to direct IANA to destroy a registry, >> or (more likely) leave a tombstone page in its place. I'll ask. >> >> -MSK >> ___ >> 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
[dmarc-ietf] picking nits with the ABNF
Just picking over the ABNF with my checks, some Qs dmarc-version = "v" equals %s"DMARC1 I believe the "%s" should be dropped dmarc-value = %x20-3A | %x3C-7E I think it should be %x20-3A / %x3C-7E and now just something suggested. The comments for URI read like this ; "URI" is imported from [RFC3986]; commas ; (ASCII 0x2C) and exclamation points ; (ASCII 0x21) MUST be encoded Could they be rewritten for readability ; "URI" is imported from [RFC3986]; ; (ASCII 0x2C) commas and ; (ASCII 0x21) exclamation points ; MUST be encoded gladly tell me i'm too obsessive thanks tim ___ 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
[dmarc-ietf] Nit: missing angle brackets
Hi, this is section 11.4, Display Name Attacks. It has: From: "u...@example.org via Bug Tracker" supp...@example.com (mailto:supp...@example.com) Should be: From: "u...@example.org via Bug Tracker" (mailto:supp...@example.com) Or even From: " via Bug Tracker" (mailto:supp...@example.com) Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another point for SPF advice
On 08/03/2024 18:45, Hector Santos wrote: I believe it is correct, SHOULD strive to trusted known sources. The final mechanism SHOULD be one of (hard) failure. This is what we (ideally) strive for. I believe anything weaker is a waste of computational resources, causes confusion using neutral or even soft fails especially with repeated transactions. A compromise seems to be to set neutral/ softfail for forwarded messages. You don't want them to be blocked, but neither you want to blindly grant occasional forwarders to originate mail with your domain name. That's not optimal. Forwarding should be fixed, e.g. by establishing streams at both sides. Another other case is for mailbox providers which don't filter against cross-domain abuse. In this case, the optimal solution is to choose better providers. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
