search

ietf-wg-dmarc / draft-ietf-dmarc-dmarcbis

5 stars 4 forks source link

DMARCbis WGLC More Nits #133

Closed toddherr closed 2 months ago

toddherr commented 5 months ago

section 11.4, Display Name Attacks. It has:

   From: "[user@example.org](mailto:user@example.org) via Bug Tracker" [support@example.com](mailto:support@example.com)
   (mailto:[support@example.com](mailto:support@example.com))

Should be:

   From: "[user@example.org](mailto:user@example.org) via Bug Tracker" <[support@example.com](mailto:support@example.com)>
   (mailto:[support@example.com](mailto:support@example.com))

Or even

   From: "<[user@example.org](mailto:user@example.org)> via Bug Tracker" <[support@example.com](mailto:support@example.com)>
   (mailto:[support@example.com](mailto:support@example.com))
toddherr commented 5 months ago

Example 3 in appendix B.1.2 uses sample.net (an existing domain) instead of example.net:

     DKIM-Signature: v=1; ...; d=[sample.net](http://sample.net/); ...
toddherr commented 5 months ago

Appendix B.1.2 Example 2 is labelled "parent" in both SPF and DKIM subsections. However, for SPF the identifier is a child of the From: domain, while for DKIM the From: domain is a child of the identifier.

I'd either label "child" the DKIM example or parallelize the roles of the identifiers.

toddherr commented 5 months ago

Section 5.4 ABNF:

dmarc-value = %x20-3A | %x3C-7E should be dmarc-value = %x20-3A / %x3C-7E

Reword comments for URI to:

            ; "URI" is imported from [RFC3986];  
            ; commas (ASCII 0x2C) and exclamation
            ; points (ASCII 0x21) MUST be
            ; encoded
toddherr commented 5 months ago

Values for 'fo' tag in section 5.3, General Record Format:

d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment. DKIM-specific reporting is described in [[RFC6651](https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/133#RFC6651)]. s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment. SPF-specific reporting is described in [[RFC6652](https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/133#RFC6652)].

should be:

d: Generate a DMARC failure report if the message had a signature that failed evaluation, regardless of its alignment. DKIM-specific reporting is described in [[RFC6651](https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/133#RFC6651)]. s: Generate an DMARC failure report if the message failed SPF evaluation, regardless of its alignment. SPF-specific reporting is described in [[RFC6652](https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/133#RFC6652)].

toddherr commented 5 months ago

Section 11.4 nit fixed with adding backslashes to precede angle brackets that were already there.

Example 3 in section B.1.2 - changed sample.net to example.net

Examples in sections B.1.1 and B.1.2 that say "(parent)" and suggestion to parallelize them...

For both sections, I've changed the labeling as follows:

The text below each example further explains each.

ABNF changes made

All changes checked in to working branch.

toddherr commented 5 months ago

Leaving 'fo' text (i.e., 'd', and 's', options) as it was in RFC 7489. The requests for DKIM-specific and SPF-specific failure reports are correct, per RFCs 6651 and 6652, respectively.

alevesely commented 5 months ago

Do RFCs 6651 and 6652 provide for sending DKIM/ SPF failure reports to the DMARC address?

toddherr commented 5 months ago

I submit that DMARC, both RFC 7489 and DMARCbis, provides for sending DKIM/SPF failure reports to the DMARC address.

RFCs 6651 and 6652 pre-date 7489, obviously, and both contain text (https://www.rfc-editor.org/rfc/rfc6651.html#section-4 and https://www.rfc-editor.org/rfc/rfc6652.html#section-3, respectively) that speak of there currently being no method defined for receiving DKIM or SPF specific failure reports. RFC 7489 and DMARCbis, which both came after, define a method for receiving these reports with the ruf tag, yes?

jrlevine commented 5 months ago

I have a folder of 89,000 failure reports sent to my ruf address, and as far as I can see, none of them are SPF or DKIM reports. So, no. Many of the DMARC failure reports are triggered by SPF or DKIM failure but that's not the same thing.

alevesely commented 5 months ago

The description of ruf=, in both DMARCbis and RFC7489 says:

RFCs 6651/2 speak of there currently being no sending method until then. They do define one. (A local part, not a mailto: URI.) If we want to define another method to send DKIM/SPF failure reports, we should do it properly. The current definition of fo= allows to receive either DMARC failure reports or DKIM/SPF ones.

alevesely commented 3 months ago

I-D-31 still has the same fo= and ruf= was enhanced to support the interpretation that fo= allows to specify different formats.

RFC7489 is very clear:

   3.  Authentication Failure Type "dmarc" is defined, which is to be
       used when a failure report is generated because some or all of
       the authentication mechanisms failed to produce aligned
       identifiers.  Note that a failure report generator MAY also
       independently produce an AFRF message for any or all of the
       underlying authentication methods.

That is:

  1. failure reports have Type "dmarc", and
  2. RFC6651/2 reports can be sent independently, not instead.

That means that the terms DKIM failure report and SPF failure report that appear in the definition of fo= are typos. The fo= tag specifies in what cases reports are wanted, not in what format. I think existing implementations interpreted it that way, although there is no errata. Am I wrong?

Of course, we may toggle the spec to mean what -31 changes seem to tend to. It may make sense, since nobody implemented RFC6651/2. If we do so, however, there has to be some extra text explaining how should those who implemented RFC6651/2 coordinate possibly conflicting configurations, and thus DMARCbis will update those RFCs too.

toddherr commented 2 months ago