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 semicolon
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
upd
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: [dmarc-i
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 w
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, ugly.
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 explic
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 fou
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 mor
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 thi
> > 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 reca
> > 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. Addin
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 of
(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 proposed
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 definit
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 b
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 close
16 matches
Mail list logo
