Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
Please reread the paragraph from section 5.3 that I quoted in the message you just replied to. You mean the following? Selective quoting is not helpful. What it actually says is: A DMARC policy record MUST comply with the formal specification found in Section 5.4 in that the "v" tag MUST be present and MUST appear first. Unknown tags MUST be ignored. Syntax errors in the remainder of the record SHOULD be discarded in favor of default values (if any) or ignored outright. You seem to imply that the first sentence is relativized by the second and third. I disagree. But that will become irrelevant anyway, as you plan to rephrase the spec there. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
It appears that Douglas Foster said: >-=-=-=-=-=- > >RFC 7489 says that the p=(none|quarantine|reject) term is required (Section >6.3, page 17). Except that section 7.1 and the examples in B.2.3 say it isn't. The syntax definitions really are a mess. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
It appears that Damian Lukowski said: >> The spec could be worded better, but you are clearly mistaken. >> Anything that starts with "v=DMARC1;" is a DMARC record. > >What is your definition of "mistaken" here? If the spec somewhere else states >that "v=DMARC1; foo=bar=baz" is a DMARC record, then >the spec is internally inconsistent, because the record does not comply with >section 5.4. Please reread the paragraph from section 5.3 that I quoted in the message you just replied to. Like I said, the spec could be clearer, and it doesn't agree very well with actual practice which is quite forgiving of junk in DMARC records. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
From the perspective of a decision problem, there are no unknown DMARC tags. If there are syntax errors, then the whole thing is not a DMARC record, in particular it does not consist of valid tag-value pairs and invalid tag-value pairs. The record v=DMARC1; rua=mailto:rep...@example.com; garbage=101; more-garbage should not yield DMARC reports at all, as there is no DMARC record. The spec could be worded better, but you are clearly mistaken. Anything that starts with "v=DMARC1;" is a DMARC record. What is your definition of "mistaken" here? If the spec somewhere else states that "v=DMARC1; foo=bar=baz" is a DMARC record, then the spec is internally inconsistent, because the record does not comply with section 5.4. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
RFC 7489 says that the p=(none|quarantine|reject) term is required (Section 6.3, page 17). We could preserve that requirement or state that p=none can also be taken as a default. On Sat, Apr 23, 2022 at 1:50 PM John Levine wrote: > It appears that Damian Lukowski said: > > From the perspective of a decision problem, there are no unknown DMARC > tags. If there are syntax errors, then the whole thing is > >not a DMARC record, in particular it does not consist of valid tag-value > pairs and invalid tag-value pairs. The record > > > >> v=DMARC1; rua=mailto:rep...@example.com; garbage=101; more-garbage > > > >should not yield DMARC reports at all, as there is no DMARC record. > > The spec could be worded better, but you are clearly mistaken. > Anything that starts with "v=DMARC1;" is a DMARC record. > > >In my opinion, the spec should either stick to the grammar, or explicitly > and unambiguously define the parsing procedure. > > > >[1] "A DMARC policy record MUST comply with the formal specification > found in Section 5.4" > > Selective quoting is not helpful. What it actually says is: > > A DMARC policy record MUST comply with the formal specification > found in Section 5.4 in that the "v" tag MUST be present and MUST > appear first. Unknown tags MUST be ignored. Syntax errors in the > remainder of the record SHOULD be discarded in favor of default values > (if any) or ignored outright. > > As I said before, I think we should fix the spec to agree with the > practice. The ones I've seen accept an arbitrary list of tag=value > pairs, ignore any trailing garbage, and do not care about tag order > other than that v=DMARC1 has to be first. > > I definitely would not say that clients have to ignore records wth > syntax errors, since implmentations will ignore that and do what they > do how. > > Re Ale's question about a the tag registry. I'd make it FCFS rather > than Specification Required since there is no risk of running out of > tag names. I'd rather know about all the tags people use, even poorly > specified ones, so we can avoid name collisions. > > 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] ABNF errors on RFC7489 and dmarcbis-07
It appears that Damian Lukowski said: > From the perspective of a decision problem, there are no unknown DMARC tags. > If there are syntax errors, then the whole thing is >not a DMARC record, in particular it does not consist of valid tag-value pairs >and invalid tag-value pairs. The record > >> v=DMARC1; rua=mailto:rep...@example.com; garbage=101; more-garbage > >should not yield DMARC reports at all, as there is no DMARC record. The spec could be worded better, but you are clearly mistaken. Anything that starts with "v=DMARC1;" is a DMARC record. >In my opinion, the spec should either stick to the grammar, or explicitly and >unambiguously define the parsing procedure. > >[1] "A DMARC policy record MUST comply with the formal specification found in >Section 5.4" Selective quoting is not helpful. What it actually says is: A DMARC policy record MUST comply with the formal specification found in Section 5.4 in that the "v" tag MUST be present and MUST appear first. Unknown tags MUST be ignored. Syntax errors in the remainder of the record SHOULD be discarded in favor of default values (if any) or ignored outright. As I said before, I think we should fix the spec to agree with the practice. The ones I've seen accept an arbitrary list of tag=value pairs, ignore any trailing garbage, and do not care about tag order other than that v=DMARC1 has to be first. I definitely would not say that clients have to ignore records wth syntax errors, since implmentations will ignore that and do what they do how. Re Ale's question about a the tag registry. I'd make it FCFS rather than Specification Required since there is no risk of running out of tag names. I'd rather know about all the tags people use, even poorly specified ones, so we can avoid name collisions. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
On Fri 22/Apr/2022 08:40:34 +0200 Damian Lukowski wrote: The record v=DMARC1; rua=mailto:rep...@example.com; garbage=101; more-garbage should not yield DMARC reports at all, as there is no DMARC record. Some later document may specify additional tags, like garbage=1*DIGIT. Tags with no value, as in more-garbage, have not yet been specified, but can become possible. Then one may raise the question of whether new tags need an RFC, or a registration suffices. Certainly there is a time gap between voicing a new syntax, starting to use it, and full specification. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
It appears that Damian Lukowski said: >> In practice, the code that parses DMARC just splits the input into >> xxx=yyy pairs of tag and value strings and checks the values >> semantically. > >For those, who do not work at the IETF, Nobody here works at the IETF. > the spec comes before the implementation. Well, sometimes. The most successful IETF standards are generally ones that document and clarify existing practice rather than that invent something totally new. >> Unknown tags MUST be ignored. Syntax errors in the remainder >> of the record SHOULD be discarded in favor of default values (if any) >> or ignored outright. Now that I look at it, the whole ABNF section is confused. I would delete the second sentence in that section, and simplify the ABNF to say that it's a mostly unordered list of tag=value clauses. Then make a second section showing the syntax of the clauses that mean something, and don't offer any advice for what to do with syntax errors. If you want to interoperate, follow the spec. If you don't follow the spec, you're on your own. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
>For those, who do not work at the IETF, the spec comes before the >implementation. If the spec defines a grammar that looks as >authoritative as the one in section 5.4, then an implementation might just >solve a decision problem whether a string matches >the grammar or not. This is a yes or no question. But as you have pointed out, >the authors have an implementation in mind that >leaks back into the spec: As an example libopendmarc [1] is willing to be "generous" : >/* >* Be generous. Accept, for example, "p=r, p=rej, or any >* left match of "reject". >*/ >if (strncasecmp((char *)vp, "reject", strlen((char *)vp)) == 0) > pctx->p = DMARC_RECORD_P_REJECT; [1] https://github.com/trusteddomainproject/OpenDMARC/blob/2aafb015a56d40e8a1949dc6d2ab0057aaf8b32f/libopendmarc/opendmarc_policy.c#L1009 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
In practice, the code that parses DMARC just splits the input into xxx=yyy pairs of tag and value strings and checks the values semantically. For those, who do not work at the IETF, the spec comes before the implementation. If the spec defines a grammar that looks as authoritative [1] as the one in section 5.4, then an implementation might just solve a decision problem whether a string matches the grammar or not. This is a yes or no question. But as you have pointed out, the authors have an implementation in mind that leaks back into the spec: Unknown tags MUST be ignored. Syntax errors in the remainder of the record SHOULD be discarded in favor of default values (if any) or ignored outright. From the perspective of a decision problem, there are no unknown DMARC tags. If there are syntax errors, then the whole thing is not a DMARC record, in particular it does not consist of valid tag-value pairs and invalid tag-value pairs. The record v=DMARC1; rua=mailto:rep...@example.com; garbage=101; more-garbage should not yield DMARC reports at all, as there is no DMARC record. In my opinion, the spec should either stick to the grammar, or explicitly and unambiguously define the parsing procedure. [1] "A DMARC policy record MUST comply with the formal specification found in Section 5.4" ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
On Thursday, April 21, 2022 1:21:22 PM EDT Olivier Hureau wrote: > Hello, > > Todd pointed out that the with the "v=DMARC1" txt records for external > verification explain why 'dmarc-request' is optional but we can still > modified the rules in this way. > > I also found out that on the with current rules : tags can be in > uppercase (the only strings that are "hardcoded" are the "DMARC1" from v > tag) and it also allow whitespace between the tag, the "=" and the value. > > As it the above TXT records are valid : > - "V=DMARC1;P=REJECT" > - "v=DMARC1; p=ReJeCt" > - "v=DMAR1; p =reject" > > A lot of dmarc libraries out there says that the records is not valid, > but according to the RFC7489 : it is. > Doing some active measurements on some email service provider i also > found that some are case/whitespace sensitive. > > I am currently writing a paper and want to submit it at the Applied > Networking Research Workshop - IETF-114. I hope I will share all my > results with you in a near future. Thanks. authheaders [1] handled the space/no space difference correctly and passed the DMARC records through with the case unchanged. I just did an update to lower case everything except DMARC1 since that seems to match most people's expectations. Scott K [1] https://github.com/ValiMail/authentication-headers ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
Hello, Todd pointed out that the with the "v=DMARC1" txt records for external verification explain why 'dmarc-request' is optional but we can still modified the rules in this way. I also found out that on the with current rules : tags can be in uppercase (the only strings that are "hardcoded" are the "DMARC1" from v tag) and it also allow whitespace between the tag, the "=" and the value. As it the above TXT records are valid : - "V=DMARC1;P=REJECT" - "v=DMARC1; p=ReJeCt" - "v=DMAR1; p = reject" A lot of dmarc libraries out there says that the records is not valid, but according to the RFC7489 : it is. Doing some active measurements on some email service provider i also found that some are case/whitespace sensitive. I am currently writing a paper and want to submit it at the Applied Networking Research Workshop - IETF-114. I hope I will share all my results with you in a near future. Regards, Olivier ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
It appears that Olivier Hureau said:
>-=-=-=-=-=-
>
>Hello,
>
>I am doing some research related to DMARC and I found some errors in the
>RFC7489 and dmarcbis-07 for ABNF rules
>
>- dmarc-percent RFC7489 :
>The rule 'dmarc-percent = "pct" *WSP "=" *WSP 1*3DIGIT' allow '999' as a value.
>a correction could be : 'dmarc-percent = "pct" *WSP "=" *WSP ("100" /
>1*2DIGIT)'
In practice, the code that parses DMARC just splits the input into
xxx=yyy pairs of tag and value strings and checks the values
semantically. So I don't see any point to changing the ABNF for this
particular value.
>- dmarc-record RFC7489 :
>The rule 'dmarc-record = dmarc-version dmarc-sep
>[dmarc-request]
>[dmarc-sep dmarc-srequest]
>[dmarc-sep dmarc-auri]
>[dmarc-sep dmarc-furi]
>[dmarc-sep dmarc-adkim]
>[dmarc-sep dmarc-aspf]
>[dmarc-sep dmarc-ainterval]
>[dmarc-sep dmarc-fo]
>[dmarc-sep dmarc-rfmt]
>[dmarc-sep dmarc-percent]
>[dmarc-sep]'
>have dmarc-request as optional but in 6.3 it says that p is "required"
That does look like a mistake.
>'dmarc-record= dmarc-version dmarc-sep dmarc-request dmarc-sep *(dmarc-tag
>dmarc-sep)
That's also a mistake. The final semicolon is optional.
Thanks for catching them.
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
Hello, Olivier, and thank you for your email.
Per RFC 7489, dmarc-request isn't actually required for some valid DMARC
records.
I direct your attention to
https://datatracker.ietf.org/doc/html/rfc7489#section-7.1, Verifying
External Destinations, in which a third-party domain that is going to
receive reports for a different domain is directed to publish a DMARC
record that contains only "v=DMARC1;".
On Thu, Apr 21, 2022 at 11:40 AM Olivier Hureau <
olivier.hur...@univ-grenoble-alpes.fr> wrote:
> Hello,
>
> I am doing some research related to DMARC and I found some errors in the
> RFC7489 and dmarcbis-07 for ABNF rules
>
> - dmarc-percent RFC7489 :
> The rule 'dmarc-percent = "pct" *WSP "=" *WSP 1*3DIGIT' allow '999' as a
> value.
> a corretion could be : 'dmarc-percent = "pct" *WSP "=" *WSP ("100" /
> 1*2DIGIT)'
>
> - dmarc-record RFC7489 :
> The rule 'dmarc-record = dmarc-version dmarc-sep
>[dmarc-request]
>[dmarc-sep dmarc-srequest]
>[dmarc-sep dmarc-auri]
>[dmarc-sep dmarc-furi]
>[dmarc-sep dmarc-adkim]
>[dmarc-sep dmarc-aspf]
>[dmarc-sep dmarc-ainterval]
>[dmarc-sep dmarc-fo]
>[dmarc-sep dmarc-rfmt]
>[dmarc-sep dmarc-percent]
>[dmarc-sep]'
> have dmarc-request as optional but in 6.3 it says that p is "required"
>
> Then i did take a look at draft-ietf-dmarc-dmarcbis-07 and the problem is
> still there :
>
> - dmarc-record dmarcbis-07 !
> 'darc-record= dmarc-version dmarc-sep *(dmarc-tag dmarc-sep)
> dmarc-tag = dmarc-request /
>dmarc-test /
>dmarc-psd /
>dmarc-sprequest /
>dmarc-nprequest /
>dmarc-adkim /
>dmarc-aspf /
>dmarc-auri /
>dmarc-furi /
>dmarc-fo /
>dmarc-rfm'
>
> Should be replaced by :
>
> 'dmarc-record= dmarc-version dmarc-sep dmarc-request dmarc-sep
> *(dmarc-tag dmarc-sep)
> dmarc-tag = dmarc-test /
>dmarc-psd /
>dmarc-sprequest /
>dmarc-nprequest /
>dmarc-adkim /
>dmarc-aspf /
>dmarc-auri /
>dmarc-furi /
>dmarc-fo /
>dmarc-rfm'
>
> Moreover, On rfc7489 the last "dmarc-sep" is optional meaning that for all
> txt records
> such as the one for gmail.com "v=DMARC1; p=none; sp=quarantine;
> rua=mailto:mailauth-repo...@google.com " the
> system administrator
> must add a ";" at the end. To avoid this source of error i suggest to change
> the ABNF as :dmarc-record= dmarc-version dmarc-sep dmarc-request *(
> dmarc-sep dmarc-tag ) [ dmarc-sep ]
> - dmarc-fo dmarcbis-07 :
> the rule ' dmarc-fo = "fo" *WSP "=" *WSP ( "0" / "1" / ( "d" / "s" / "d:s" /
> "s:d" ) )' does not allow the user to have both DMARC failure report
> and DKIM/SPF failure report at the same time as '0:d', '1:d' is not allowed.
>
> Best regards,
>
> Olivier HUREAU
> ---
> PhD Student
> Laboratoire Informatique Grenoble - UGA - Drakkar
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 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
[dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
Hello,
I am doing some research related to DMARC and I found some errors in the
RFC7489 and dmarcbis-07 for ABNF rules
- dmarc-percent RFC7489 :
The rule 'dmarc-percent = "pct" *WSP "=" *WSP 1*3DIGIT' allow '999' as a value.
a corretion could be : 'dmarc-percent = "pct" *WSP "=" *WSP ("100" / 1*2DIGIT)'
- dmarc-record RFC7489 :
The rule 'dmarc-record = dmarc-version dmarc-sep
[dmarc-request]
[dmarc-sep dmarc-srequest]
[dmarc-sep dmarc-auri]
[dmarc-sep dmarc-furi]
[dmarc-sep dmarc-adkim]
[dmarc-sep dmarc-aspf]
[dmarc-sep dmarc-ainterval]
[dmarc-sep dmarc-fo]
[dmarc-sep dmarc-rfmt]
[dmarc-sep dmarc-percent]
[dmarc-sep]'
have dmarc-request as optional but in 6.3 it says that p is "required"
Then i did take a look at draft-ietf-dmarc-dmarcbis-07 and the problem is still
there :
- dmarc-record dmarcbis-07 !
'darc-record= dmarc-version dmarc-sep *(dmarc-tag dmarc-sep)
dmarc-tag = dmarc-request /
dmarc-test /
dmarc-psd /
dmarc-sprequest /
dmarc-nprequest /
dmarc-adkim /
dmarc-aspf /
dmarc-auri /
dmarc-furi /
dmarc-fo /
dmarc-rfm'
Should be replaced by :
'dmarc-record= dmarc-version dmarc-sep dmarc-request dmarc-sep *(dmarc-tag
dmarc-sep)
dmarc-tag = dmarc-test /
dmarc-psd /
dmarc-sprequest /
dmarc-nprequest /
dmarc-adkim /
dmarc-aspf /
dmarc-auri /
dmarc-furi /
dmarc-fo /
dmarc-rfm'
Moreover, On rfc7489 the last "dmarc-sep" is optional meaning that for all txt
records
such as the one for gmail.com"v=DMARC1; p=none; sp=quarantine;
rua=mailto:mailauth-repo...@google.com"; the system administrator must
add a ";" at the end. To avoid this source of error i suggest to change
the ABNF as :
dmarc-record = dmarc-version dmarc-sep dmarc-request *( dmarc-sep
dmarc-tag ) [ dmarc-sep ]
- dmarc-fo dmarcbis-07 :
the rule ' dmarc-fo = "fo" *WSP "=" *WSP ( "0" / "1" / ( "d" / "s" / "d:s" /
"s:d" ) )' does not allow the user to have both DMARC failure report
and DKIM/SPF failure report at the same time as '0:d', '1:d' is not allowed.
Best regards,
Olivier HUREAU
---
PhD Student
Laboratoire Informatique Grenoble - UGA - Drakkar
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
