Subject: Re: [dmarc-ietf] New Version Notification for draft-kucherawy-dmarc-dmarcbis-01.txt

From: Tim Wicinski <[email-masked]>
Date: Mon, 6 Apr 2020 13:21:56 -0400

Updates to draft-kucherawy-dmarc-dmarcbis

    updated IANA Considerations to reflect new DNS Underscore Registry
https://trac.ietf.org/trac/dmarc/ticket/36

    Moved xml schema to own versioned document

    Fixed internal cross reference issue

    Edits to escape _ properly

    Fixed references to RFC6651

    Updated Obsolete References https://trac.ietf.org/trac/dmarc/ticket/35

I also pulled the ABNF out into its own file, and I've been looking at a
few of the tickets

around updating the ABNF, and how we could validate it.   This led to a
long discussion with

Mr. Levine about a better way to track external references to ABNF objects.

There are several tickets related to ABNF and several related to the XML,
and that's before

we go through the document itself.

the XML schema has several issues in the issue tracker, and it seemed to
make sense to pull it out so it can also be referenced by others.  Very
useful discussions with Mr.  Vesely and Mr. Levine on versioning the XML
schema and some of the open issues

https://github.com/moonshiner/draft-kucherawy-dmarc-dmarcbis

On Mon, Apr 6, 2020 at 1:19 PM <[email-masked]> wrote:

>
> A new version of I-D, draft-kucherawy-dmarc-dmarcbis-01.txt
> has been successfully submitted by Tim Wicinski and posted to the
> IETF repository.
>
> Name:           draft-kucherawy-dmarc-dmarcbis
> Revision:       01
> Title:          Domain-based Message Authentication, Reporting, and
> Conformance (DMARC)
> Document date:  2020-04-06
> Group:          Individual Submission
> Pages:          73
> URL:
> https://www.ietf.org/internet-drafts/draft-kucherawy-dmarc-dmarcbis-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/
> Htmlized:
> https://tools.ietf.org/html/draft-kucherawy-dmarc-dmarcbis-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kucherawy-dmarc-dmarcbis
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dmarc-dmarcbis-01
>
> Abstract:
>    Domain-based Message Authentication, Reporting, and Conformance
>    (DMARC) is a scalable mechanism by which a mail-originating
>    organization can express domain-level policies and preferences for
>    message validation, disposition, and reporting, that a mail-receiving
>    organization can use to improve mail handling.
>
>    Originators of Internet Mail need to be able to associate reliable
>    and authenticated domain identifiers with messages, communicate
>    policies about messages that use those identifiers, and report about
>    mail using those identifiers.  These abilities have several benefits:
>    Receivers can provide feedback to Domain Owners about the use of
>    their domains; this feedback can provide valuable insight about the
>    management of internal operations and the presence of external domain
>    name abuse.
>
>    DMARC does not produce or encourage elevated delivery privilege of
>    authenticated email.  DMARC is a mechanism for policy distribution
>    that enables increasingly strict handling of messages that fail
>    authentication checks, ranging from no action, through altered
>    delivery, up to message rejection.
>
>    This document obsoletes RFC 7489.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 7 Apr 2020 12:43:52 +0200

On Mon 06/Apr/2020 19:21:56 +0200 Tim Wicinski wrote:
> [...]
> [...]
>> Htmlized: https://tools.ietf.org/html/draft-kucherawy-dmarc-dmarcbis-01

I took a look at the new doc's diffs, and found a few nits:

*RFC3986 instead of RFC7208*

In some places this was wrongly replaced.  I found:

- In relaxed mode, the [RFC3986]-authenticated domain
- [RFC3986], which can authenticate both the domain
- when a message fails both [RFC3986] and [RFC6376]

*RFC3986 instead of URI*

The following snippet is quite unreadable:

   When a Mail Receiver discovers a DMARC policy in the DNS, and the
   Organizational Domain at which that record was discovered is not
   identical to the Organizational Domain of the host part of the
   authority component of a [RFC3986] specified in the "rua" or "ruf"
   tag, the following verification steps are to be taken:

Would "The component of a URI ([RFC3986]) specified in..." be better?

*Semicolon in the version tag*

DMARC records follow the extensible "tag-value" syntax for DNS-based key
records defined in DKIM, which says:

   Note that WSP is allowed anywhere around tags.  In particular, any
   WSP after the "=" and any WSP before the terminating ";" is not part
   of the value; however, WSP inside the value is significant.
                       https://tools.ietf.org/html/rfc6376#section-3.2

This seems to imply that "v = DMARC1 ;" (with spaces) is valid.  In addition, a
tag is specified as:

   tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]

That is, without a trailing semicolon.  So it sound confusing to insist on the
semicolon, as in «a tag of "v=DMARC1;"», «containing at least "v=DMARC1;"», and

   *  The version of DMARC being used is "DMARC1" ("v=DMARC1;")

*Repeated URIs*

Sometimes URIs are redundantly repeated in parentheses.  I found:

   common one is maintained by the Mozilla Foundation and made public at
   http://publicsuffix.org (http://publicsuffix.org).

      From: "[email-masked] via Bug Tracker" [email-masked]
      (mailto:[email-masked])

and

   an informal industry consortium: DMARC.org (see http://dmarc.org
   (http://dmarc.org)).

jm2c
Ale
--