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
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.
--
Les
From: dmarc On Behalf Of Murray S. Kucherawy
Sent: Monday, June 6, 2022 2:28 PM
To: IETF DMARC WG
Subject: Re:
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 RFC 7405? It is
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
16 matches
Mail list logo