It appears that Alessandro Vesely said:
>On Tue 07/Jun/2022 04:03:35 +0200 John Levine wrote:
>> Here's my alternate take: make the ABNF a lot simpler to
>> reflect the actual loose syntax.
>>
>> dmarc-record= dmarc-version *(*WSP ";" *WSP dmarc-tag) *WSP *%x3b
>>
>> dmarc-tag
It appears that Todd Herr said:
>-=-=-=-=-=-
>
>On Mon, Jun 6, 2022 at 10:03 PM John Levine wrote:
>
>>
>> dmarc-tag = 1*ALPHA %WSP '=' *WSP 1*dmarc-value
>>
>>
>
>Is there a typo here? That is, should it be:
>
> dmarc-tag = 1*ALPHA *WSP '=' *WSP 1*dmarc-value
>
>(asterisk
Ale writes (in part):
>>> dmarc-rfmt = Keyword *(*WSP ":" Keyword)
>>> ; registered reporting formats only
>>>
>>> "Keyword" is imported from Section 4.1.2 of [RFC5321].
>After 7 years, there is still only afrf. What do we expect?
IODEF to rise from the grave?
On Tue 07/Jun/2022 04:03:35 +0200 John Levine wrote:
Here's my alternate take: make the ABNF a lot simpler to
reflect the actual loose syntax.
dmarc-record= dmarc-version *(*WSP ";" *WSP dmarc-tag) *WSP *%x3b
dmarc-tag = 1*ALPHA %WSP '=' *WSP 1*dmarc-value
dmarc-value
On Mon, Jun 6, 2022 at 10:03 PM John Levine wrote:
>
> dmarc-tag = 1*ALPHA %WSP '=' *WSP 1*dmarc-value
>
>
Is there a typo here? That is, should it be:
dmarc-tag = 1*ALPHA *WSP '=' *WSP 1*dmarc-value
(asterisk replacing the percent sign before the first WSP)
--
*Todd Herr
I am all about simpler ABNF
+1
Simple Tim
On Mon, Jun 6, 2022 at 10:03 PM John Levine wrote:
> Here's my alternate take: make the ABNF a lot simpler to
> reflect the actual loose syntax.
>
> dmarc-record= dmarc-version *(*WSP ";" *WSP dmarc-tag) *WSP *%x3b
>
> dmarc-tag =
Here's my alternate take: make the ABNF a lot simpler to
reflect the actual loose syntax.
dmarc-record= dmarc-version *(*WSP ";" *WSP dmarc-tag) *WSP *%x3b
dmarc-tag = 1*ALPHA %WSP '=' *WSP 1*dmarc-value
dmarc-value = %x20-3a | %x3c-7e ; any printing chars but
On Mon, Jun 6, 2022 at 1:40 PM Les Barstow wrote:
> As Barry pointed out, RFC7405 does provide the %s notation. But since your
> voice was added on top of mine, I might point out that 7405 is only
> proposed, not accepted.
>
No, it's an RFC that had IETF consensus to publish, and it shows as
-ietf] Updating ABNF for Next Rev?
Speaking as a participant: On Mon, Jun 6, 2022 at 10:12 AM Alessandro Vesely
mailto:ves...@tana.it>> wrote: > dmarc-version = "v"
*WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31 Can we use RFC 7405? It is more
readable:
Speak
Speaking as a participant:
On Mon, Jun 6, 2022 at 10:12 AM Alessandro Vesely wrote:
> > dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31
>
>
> Can we use RFC 7405? It is more readable:
>
> dmarc-version = "v" *WSP "=" *WSP %s"DMARC1" ; case sensitive
>
+1 to
On a technical note, “0” and “1” generate DMARC failure reports, while “d”
produces a DKIM failure report and “s” produces an SPF failure report. They are
slightly different in content (and specification). Technically, I suppose
“0:d:s” could produce one of each. That is, to put it mildly,
On Mon, Jun 6, 2022 at 3:49 PM Olivier Hureau <
olivier.hur...@univ-grenoble-alpes.fr> wrote:
>
> > dmarc-fo = "fo" *WSP "=" *WSP ( "0" / "1" / ( "d" / "s" / "d:s" /
> "s:d" ) )
>
> What about domain owner that have a value that is not listed there ? ex:
> "1:d" or even "1:d:s" ? (4.59% of
Hi,
> dmarc-record = dmarc-version dmarc-sep *(dmarc-tag dmarc-sep)
The problem there is the dmarc-sep must be present at the end. Indeed,
as defined in RFC7489 it is not mandatory and a lot of current existing
DMARC records do not ends with dmarc-sep : 74.05% of the valid DMARC
records I
This is what happens when you aren’t involved in regular RFC discussions.
Sorry, my lack of patience got me.
--
Les
From: Barry Leiba
Sent: Monday, June 6, 2022 12:03 PM
To: Les Barstow
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Updating ABNF for Next Rev?
> > Can we use RF
On Mon, Jun 6, 2022 at 2:09 PM Barry Leiba wrote:
> Another point on readability:
>
> > > dmarc-request = "p" *WSP "=" *WSP
> > > ( "none" / "quarantine" / "reject" )
>
> Quite a few constructs include this: *WSP "=" *WSP
>
> Is it worth creating something like
> > dmarc-record= dmarc-version dmarc-sep *(dmarc-tag dmarc-sep)
>
> No, in April we said something like so:
>
> dmarc-record= dmarc-version *(dmarc-sep dmarc-tag) [dmarc-sep]
Indeed; the difference between "must end with dmarc-sep" and "may end
with dmarc-sep". I also
> > Can we use RFC 7405? It is more readable:
> > dmarc-version = "v" *WSP "=" *WSP %s"DMARC1" ; case sensitive
>
> The ABNF definition suggests that anything in double-quotes is case
> insensitive, and that any case-sensitive
> values should be escaped as per the -07 definition.
On Mon, Jun 6, 2022 at 1:47 PM Les Barstow wrote:
>
>
> On Monday, June 6, 2022 9:06 AM Todd Herr wrote:
>
>
>
> > Back in late April, after rev -07 of DMARCbis was released, there was
> on-list discussion focused on the ABNF bits (section 5.4), and a need to
> revise them. There was also talk
(Copying to list – mail software user fail)
On Monday, June 6, 2022 9:06 AM Todd Herr wrote:
> Back in late April, after rev -07 of DMARCbis was released, there was on-list
> discussion focused on the ABNF bits (section 5.4), and a need to revise them.
> There was also talk of possible
Ale writes:
> Can we use RFC 7405? It is more readable:
> dmarc-version = "v" *WSP "=" *WSP %s"DMARC1" ; case sensitive
The ABNF definition suggests that anything in double-quotes is case
insensitive, and that any case-sensitive values should be escaped as per the
-07
On Mon 06/Jun/2022 17:06:05 +0200 Todd Herr wrote:
Here's what's currently written in rev -07 for the subject at hand:
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
Greetings.
Back in late April, after rev -07 of DMARCbis was released, there was
on-list discussion focused on the ABNF bits (section 5.4), and a need to
revise them. There was also talk of possible proposed text, but I don't
recall ever seeing any, so I want to start a new thread to try and
22 matches
Mail list logo