Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
On Wed 27/Mar/2024 13:17:57 +0100 Matthäus Wander wrote: Alessandro Vesely wrote on 2024-03-27 10:00: I'm not clear what will that schema be used for, if at all. Personally, the only reason why I'd prefer the long regex is because it might have some value by itself. The short one is cleaner and more grokkable. The wrong one has none of those qualities. I see the following use cases for the schema (sorted from most to least important): 1) Provide a precise description to implementers (of both report senders and receivers) how a report should look like. 2) Allow report senders to verify the correctness of their implementation. 3) Allow report receivers to perform input validation before ingesting a report. I guess (3) bears the least important because report receivers don't care about the schema and just look for the elements they recognize. If the schema were to be continuously used several times a day, simplifying would be a must. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
Alessandro Vesely wrote on 2024-03-27 10:00:
I changed that to /[0-9a-fA-F.:]{2,45}/, to allow "::", and inserted it
in dmarc-xml-0.2-short.xsd[*]. At the same time, I added a pattern for
"::1.2.3.4" in dmarc-xml-0.2.xsd[†].
I can live with either of these variants.
I'm not clear what will that schema be used for, if at all. Personally,
the only reason why I'd prefer the long regex is because it might have
some value by itself. The short one is cleaner and more grokkable. The
wrong one has none of those qualities.
I see the following use cases for the schema (sorted from most to least
important):
1) Provide a precise description to implementers (of both report senders
and receivers) how a report should look like.
2) Allow report senders to verify the correctness of their implementation.
3) Allow report receivers to perform input validation before ingesting a
report.
Regards,
Matt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
On Tue 26/Mar/2024 21:57:46 +0100 Matthäus Wander wrote:
Alessandro Vesely wrote on 2024-03-26 19:30:
No. To take several years and come up with a syntax which does not cover all
valid addresses is a sign of incompetence that this WG doesn't deserve, IMHO.
What do others think?
Let's rather switch to /[0-9a-fA-F.:]+/. Terse and correct.
I'm in favor of a brief and coarse regex, which is suitable for detecting
obvious junk. The above proposal looks good enough to me. I wouldn't mind
adding an outer bounds check, e.g.: [0-9a-fA-F.:]{3,45}
I changed that to /[0-9a-fA-F.:]{2,45}/, to allow "::", and inserted it in
dmarc-xml-0.2-short.xsd[*]. At the same time, I added a pattern for "::1.2.3.4" in
dmarc-xml-0.2.xsd[†]. I tested both against the list of IP that I attach. (xmllint allows
breaking a pattern by backslash+newline, svalidate and xmlstarlet don't. However, publishing on
IETF XML Registry shouldn't have line length limitations.)
If an implementer sees merit in a comprehensive syntax check, they can add one
to their software.
I'm not clear what will that schema be used for, if at all. Personally, the
only reason why I'd prefer the long regex is because it might have some value
by itself. The short one is cleaner and more grokkable. The wrong one has
none of those qualities.
Best
Ale
--
[*]
https://github.com/alevesely/draft-ietf-dmarc-aggregate-reporting/blob/main/dmarc-xml-0.2-short.xsd
[†]
https://github.com/alevesely/draft-ietf-dmarc-aggregate-reporting/blob/main/dmarc-xml-0.2.xsd
2001:db8:0:0:1:0:0:1
2001:0db8:0:0:1:0:0:1
2001:db8::1:0:0:1
2001:db8::0:1:0:0:1
2001:0db8::1:0:0:1
2001:db8:0:0:1::1
2001:db8::0:1::1
2001:DB8:0:0:1::1
2001:db8::::::0001
2001:db8::::::001
2001:db8::::::01
2001:db8::::::1
2001:db8::::::1
2001:db8:::::0:1
2001:db8:0:0:0::1
2001:db8:0:0::1
2001:db8:0::1
2001:db8::1
2001:db8:::0:0:1
2001:db8:0:0:::1
2001:db8::::::
2001:db8::::::
2001:db8::::::AaAa
ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
2001:DB8:0:0:8:800:200C:417A
2001:DB8:0:0:8:800:200C:417A
FF01:0:0:0:0:0:0:101
0:0:0:0:0:0:0:1
0:0:0:0:0:0:0:0
2001:DB8::8:800:200C:417A
FF01::101
::1
::
0:0:0:0:0:0:13.1.68.3
0:0:0:0:0::129.144.52.38
::13.1.68.3
:::129.144.52.38
:::12.34.56.78
::0::12.34.56.78
::00::12.34.56.78
::000::12.34.56.78
::::12.34.56.78
::0:00::12.34.56.78
::00:00::12.34.56.78
::000:00::12.34.56.78
:::00::12.34.56.78
::0:0:0::12.34.56.78
::0:0:00::12.34.56.78
::0:00:00::12.34.56.78
::0:0:000::12.34.56.78
::0::0::12.34.56.78
::00:0:0::012.034.056.078
::0:00:0::012.034.056.078
::0:0:00::012.034.056.078
::000:0:0::012.034.056.078
::0:000:0::012.034.056.078
::0:0:000::012.034.056.078
:::0:::012.034.056.078
::
::1
1::
0::
0.0.0.0
1.0.0.0
0.1.0.0
0.0.1.0
0.0.0.1
a::b
0:a:b::
0:0:a::b
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
Alessandro Vesely wrote on 2024-03-26 19:30:
No. To take several years and come up with a syntax which does not
cover all valid addresses is a sign of incompetence that this WG doesn't
deserve, IMHO. What do others think?
Let's rather switch to /[0-9a-fA-F.:]+/. Terse and correct.
I'm in favor of a brief and coarse regex, which is suitable for
detecting obvious junk. The above proposal looks good enough to me. I
wouldn't mind adding an outer bounds check, e.g.: [0-9a-fA-F.:]{3,45}
If an implementer sees merit in a comprehensive syntax check, they can
add one to their software.
Regards,
Matt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
On Tue 26/Mar/2024 16:18:31 +0100 John R Levine wrote: ::00::12.34.56.78 0:0:0:0:0:0::012.034.056.078 The latter yields failure running the example program in the inet_pton(3) man page. See e.g. https://www.man7.org/linux/man-pages/man3/inet_pton.3.html#EXAMPLES My bad. After checking RFC 4291, 0:0:0:0:0::012.034.056.078 is valid. So are 0:0:0:0:0:0:012.034.056.078 or ::12.34.56.78. That's yet another reason not to change the XML spec. Please stop. No. To take several years and come up with a syntax which does not cover all valid addresses is a sign of incompetence that this WG doesn't deserve, IMHO. What do others think? Let's rather switch to /[0-9a-fA-F.:]+/. Terse and correct. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
::00::12.34.56.78 0:0:0:0:0:0::012.034.056.078 The latter yields failure running the example program in the inet_pton(3) man page. See e.g. https://www.man7.org/linux/man-pages/man3/inet_pton.3.html#EXAMPLES That's yet another reason not to change the XML spec. Please stop. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
On Mon 25/Mar/2024 18:54:14 +0100 John R Levine wrote:
On Mon, 25 Mar 2024, Alessandro Vesely wrote:
How about:
"(:::)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/>
Testing yielded a correct fix:
"(::[Ff]{4}:)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/>
There are lots of other ways to write it, e.g.
::00::12.34.56.78
0:0:0:0:0:0::012.034.056.078
The latter yields failure running the example program in the inet_pton(3) man
page. See e.g.
https://www.man7.org/linux/man-pages/man3/inet_pton.3.html#EXAMPLES
Curiously, I get:
ale@pcale:~/tmp$ ./a.out i6 0:0:0::5:6:7:8
:::5:6:7:8
ale@pcale:~/tmp$ ./a.out i6 0:0:0::5.6.7.8
Not in presentation format
ale@pcale:~/tmp$ ./a.out i6 0:0:0:0:0::5.6.7.8
:::5.6.7.8
and they're actually IPv6 addresses. Just take it out, if nobody has tried to
use this form in the past decade, they won't use it now.
That is not true. We are not verifying the grammar of all aggregate reports.
It may well be that people uses those forms even if we didn't see them.
Leading zeroes can be accommodated in the regex. The number of ways you can
write IP addresses is not infinite. Strings accepted by inet_pton() should
pass the regex. We can either fix the regex and test it, or switch to a lax
/[0-9a-fA-F.:]+/.
To accommodate the formats above (except inet_pton() bugs), the first line can
be:
"0{1,4}:){3})|(::(0{1,4}:){0,2}))([Ff]{4}:))?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/>
In addition, to account for "::", the last line should change to:
For sure the grammar needs more testing. An example is the error element:
This element is inside an xs:all, where elements can appear in any order. That model
implies they can either appear or not inside xs:all. Thus "unbounded" is not
allowed.
https://www.w3.org/TR/xmlschema11-1/#declare-contentModel
Best
Ale
--
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
Apologies, which format should be used. I'm not sure if I should revert to the
one from 7489, or some other prior version.
The one that's in the draft now is fine. Don't add the line with f{4}
which is an insufficiently general special case.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
Apologies, which format should be used. I'm not sure if I should revert to the
one from 7489, or some other prior version.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: dmarc On Behalf Of John R Levine
> Sent: Monday, March 25, 2024 1:54 PM
> To: Alessandro Vesely ; dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
>
> On Mon, 25 Mar 2024, Alessandro Vesely wrote:
> >> How about:
> >> "(:::)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|2
> >> 5[0-5])"/>
> >
> >
> > Testing yielded a correct fix:
> >
> >
> > "(::[Ff]{4}:)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d
> > |25[0-5])"/>
>
> There are lots of other ways to write it, e.g.
>
> ::00::12.34.56.78
> 0:0:0:0:0:0::012.034.056.078
>
> and they're actually IPv6 addresses. Just take it out, if nobody has tried
> to use
> this form in the past decade, they won't use it now.
>
> > Please take my pull request.
>
> Please take out the grammar change.
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please
> consider the environment before reading this e-mail.
> https://urldefense.com/v3/__https://jl.ly__;!!CQl3mcHX2A!GrQN5Qa27kbjTdAl8T
> v9N3x0TKJwgntlZNJu0MEv_JDN0Gg6YDL6eEv4lISkNj27tfirjRuQ0seUN9tU$
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C
> Ql3mcHX2A!GrQN5Qa27kbjTdAl8Tv9N3x0TKJwgntlZNJu0MEv_JDN0Gg6YDL6eEv
> 4lISkNj27tfirjRuQ0vfo69EU$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
On Mon, 25 Mar 2024, Alessandro Vesely wrote:
How about:
"(:::)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/>
Testing yielded a correct fix:
"(::[Ff]{4}:)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/>
There are lots of other ways to write it, e.g.
::00::12.34.56.78
0:0:0:0:0:0::012.034.056.078
and they're actually IPv6 addresses. Just take it out, if nobody has
tried to use this form in the past decade, they won't use it now.
Please take my pull request.
Please take out the grammar change.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
On Sun 24/Mar/2024 13:33:22 +0100 Alessandro Vesely wrote:
On Sat 23/Mar/2024 19:53:39 +0100 John Levine wrote:
It appears that Murray S. Kucherawy said:
-=-=-=-=-=-
This seems like it's probably legitimate. Does it need to be fixed in the
-bis document?
It's already fixed in the current markdown.
FYI, the XML pattern is silly. It forbids harmless stuff like leading zeros
in 01.02.03.04
and doesn't allow some exotic but valid IPv6 forms like :::12.34.56.78.
How about:
"(:::)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/>
Testing yielded a correct fix:
"(::[Ff]{4}:)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/>
I'd agree it might have been better to allow an overly lax pattern, such as
"[0-9a-fA-F.:]+". When we (Tim and I) got to revise the grammar from Freddie's work
on docs.google.com, in March 2020, we tried and followed the style of RFC 7489. That led to
the current grammar under the comment . Obviously we hadn't tested all cases. Now you (John) found a case. Why
shouldn't we fix it? Why would it be too late, since we're in WGLC? Why would it be the wrong
place?
Note: the change doesn't make the grammar stricter than it is. It makes it
slightly more relaxed.
Please take my pull request.
Best
Ale
--
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
On Sat 23/Mar/2024 19:53:39 +0100 John Levine wrote:
It appears that Murray S. Kucherawy said:
-=-=-=-=-=-
This seems like it's probably legitimate. Does it need to be fixed in the
-bis document?
It's already fixed in the current markdown.
FYI, the XML pattern is silly. It forbids harmless stuff like leading zeros in
01.02.03.04
and doesn't allow some exotic but valid IPv6 forms like :::12.34.56.78.
How about:
"(:::)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|25[0-5])"/>
Best
Ale
--
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >This seems like it's probably legitimate. Does it need to be fixed in the >-bis document? It's already fixed in the current markdown. FYI, the XML pattern is silly. It forbids harmless stuff like leading zeros in 01.02.03.04 and doesn't allow some exotic but valid IPv6 forms like :::12.34.56.78. It's not worth changing now, but when we do something like this in the future it's more sensible to have a simpler over-general pattern and a note saying it's semantically limited to valid values. > >-MSK > >-- Forwarded message - >From: RFC Errata System >Date: Sat, Mar 23, 2024 at 8:04 AM >Subject: [Technical Errata Reported] RFC7489 (7865) >To: , , >Cc: , > > >The following errata report has been submitted for RFC7489, >"Domain-based Message Authentication, Reporting, and Conformance (DMARC)". > >-- >You may review the report below and at: >https://www.rfc-editor.org/errata/eid7865 > >-- >Type: Technical >Reported by: Fränz Friederes > >Section: Appendix C > >Original Text >- > > > > > > > > >Corrected Text >-- > > > > > > > > >Notes >- >The IPv4 regex contains a period "." that should be corrected to an escaped >period "\." As stated in the follow up message of the one referenced in the >IPv4 regex credit: "I just realized that there is a bug [...] The period >(.) is a special character meaning 'any character'. To indicate that we >want a period and not 'any character' the period must be escaped with a >backslash, i.e., \." Following the XML schema provided in the original >Appendix C, strings like "1a1a1a1" and "111" are considered valid IPv4 >addresses, although they are not usable. > >Instructions: >- >This erratum is currently posted as "Reported". (If it is spam, it >will be removed shortly by the RFC Production Center.) Please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party >will log in to change the status and edit the report, if necessary. > >-- >RFC7489 (draft-kucherawy-dmarc-base-12) >-- >Title : Domain-based Message Authentication, Reporting, and >Conformance (DMARC) >Publication Date: March 2015 >Author(s) : M. Kucherawy, Ed., E. Zwicky, Ed. >Category: INFORMATIONAL >Source : INDEPENDENT >Stream : INDEPENDENT >Verifying Party : ISE & Editorial Board > >-=-=-=-=-=- >[Alternative: text/html] >-=-=-=-=-=- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
Murray S. Kucherawy wrote on 2024-03-23 19:04: This seems like it's probably legitimate. Does it need to be fixed in the -bis document? It has been already fixed in aggregate-reporting: Regards, Matt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
