Prodded by 1&1 recently implementing this draft standard, I am looking
through the documents intended to replace RFC7489.
I'm unfamiliar with the IETF process, so please excuse me if I'm
worrying about something that will be handled at a later stage.
1) Errata from RFC 7489 is not incorporated into the text.
There is a list of errata in draft-ietf-dmarc-dmarcbis-33, Section C.9,
RFC 7489 Errata Summary, and it mostly says:
To be addressed in [I-D.ietf-dmarc-aggregate-reporting].
Should this not be done at this stage, or will this be handled by the
I-D to RFC process somehow, by a different editor?
Going through the list I would have expected different resolution
proposals for some of the errata.
Errata: 5365 (filename suffix), 5371 (GZIP RFC reference):
Both seem to be uncontroversial and should be addressed in
[I-D.ietf-dmarc-aggregate-reporting].
Erratum 5440 (changing: "v=DMARC1" to "v=DMARC1;")
The ABNF was changed, so the semicolon is now optional. This is only
relevant for _report._dmarc. type TXT records without tags, where
"v=DMARC1" is now allowed by the updated ABNF.
For normal DMARC Policy Records the p tag is required, and hence a ";"
must be present after the v=DMARC, however optional WSP is allowed so
"v=DMARC ;" or even "v = DMARC1 ;" should be equally valid. The text as
written gives the impression that no WSP is allowed.
Should the _report._dmarc value get its own ABNF with only rua/ruf tags?
Right now I see this record referred to as a TXT RR:
the DNS administrator for the Report Consumer will
need to publish a TXT resource record at [...] with
the value
"v=DMARC1;".
Maybe it could be referred to as a DMARC Report
Erratum 6439 (comparing host vs Organizational Domain)
I believe "Verifying External Destinations" should be updated both in
the aggregate-reporting and failure-reporting drafts.
Erratum 6485 (Report-ID ABNF: allowed value)
See the next item.
Erratum 7835 (Remove duplicate filtering step)
I believe this erratum to be invalid, as the 'duplicate' step is not
really duplicate, it is the same operation applied to different data.
2) Botched ABNF for 'ridtxt' in the txt version of the document.
Looking further, it looks like a problem with conversion due to missing
``` or ~~~ markers around the ABNF in the markdown.
3) ABNF for 'ridtxt' is too strict
Regarding ridtxt, the value for "Report-ID:"; I think I saw some place
or understood from the context, that the relaxed rules was to sanction
the current usage seen in the wild:
dmarc-subject = ... [ %s"Report-ID:" 1*FWS ridtxt ]
ridtxt = ("<" *(ALPHA / DIGIT / "." / "-")
["@" *(ALPHA / DIGIT / "." / "-")] ">")
/ (*(ALPHA / DIGIT / "." / "-")
["@" *(ALPHA / DIGIT / "." / "-")])
The 'ALPHA / DIGIT / "." / "-"' seems overly strict, and it does not
match what's in the wild, where at least "=" "$" "_" and "!" has been
seen by us.
I suggest to relax it further, e.g. as follows:
ridfmt = (dot-atom-text ["@" dot-atom-text])
; from RFC5322
ridtxt = ("<" ridfmt ">") / ridfmt
This also makes it more obvious that the angle brackets are now optional.
Further, At least fortimail and fastmail do not add the required FWS
after "Report-ID:"
4) This warning text is sometimes shown even if
there's no need to wrap the command output:
(the output shown would appear on a single
line
but is wrapped here for publication):
5) Overlap in the examples of dmarcbis and failure-reporting
With some wording differences that seem to stem from text being copied,
the worked on in one draft only.
Entire Domain, Monitoring Mode vs.
Entire Domain, Monitoring Only, Per-Message Reports
failure-reporting should also talk about per-message reports, but
"monitoring mode" is new wording for "monitoring only"
Maybe all examples should go in the main document. That way the examples
does not need to be disentangled from each other.
6) Inconsistent requirements for validating third party report consumers.
In: Per-Message Failure Reports Directed to Third Party, a few
paragraphs apart.
Mail Receivers [that send reports to third parties] may implement
additional checks
vs.
conforming Mail Receivers will implement additional checks
Should the wording be upgraded to a "MUST implement additional checks"?
7) Formal definition
"Keyword" is no longer referenced, and the note about it being imported
from RFC 5321 can be dropped.
8) The txt versions are hard to read
Due to: (#identifiers) interspersed throughout the text
Instances of "HEADER" VSPACE pagebreak ("list" / "paragraph")
Maybe there exists markup to convince the generator to keep the header
together with the content, or is it expected that the "professional
editor" will fix up all these things?
9) XSD Schema
The IPAddress type has a mix of [A-Fa-f0-9] and [A-Fa-f\d] in the
patterns. Use only one of them for consistency.
That's it for now. I'm not opposed to editing the markdown from GitHub
and making pull requests, but I'd like some guiding reactions to my
comments before I continue. Maybe I'm worrying about nothing, maybe this
uncovers a need for a bigger rewrite, or something in between.
Daniel K.
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
