Subject: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02

From: Barry Leiba <[email-masked]>
Date: Sun, 15 Jul 2018 14:04:51 -0400

So begins Working Group Last Call (WGLC) on draft-ietf-dmarc-rfc7601bis-02.

Please review the latest version:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/
... and send comments to the DMARC working group mailing list by 3 August.

If you review it and think it's ready to go and you have no comments,
please post that as well.
-- 
Barry, DMARC chair

---

From: Seth Blank <[email-masked]>
Date: Mon, 16 Jul 2018 09:56:16 -0700

I've reviewed. All the technical matters look good, and earlier comments
have all been addressed. I have two final comments:

1) Section 6.4 mentions changes to section 2.3 which include slightly
different language than in 7601. I see no difference whatsoever (walking
back diffs 02-01, 01-00) between the current text in 2.3 and what's in 2.3
of 7601. The text is supposed to be loosened so things like smtp.client-ip
and arc.oldest-pass info for ARC A-R stamps are allowable in the registry.

2) Typo: Section 2.2 references "sob-domain"

Final thought: the inclusion of authres-payload as inheritable ABNF and the
addition of EAI language in this update will be both quite valuable. I'm
looking forward to seeing this published.

Seth

On Sun, Jul 15, 2018 at 11:04 AM, Barry Leiba <[email-masked]>
wrote:

> .... and send comments to the DMARC working group mailing list by 3 August.
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Jul 2018 21:48:22 +0000

> and arc.oldest-pass info for ARC A-R stamps are allowable in the registry.

https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-rfc7601bis-01&url2=rfc7601

They're inverted (RFC7601 is on the right) but have a look at 2.3.

Fixed in source.

-MSK

---

From: Seth Blank <[email-masked]>
Date: Mon, 16 Jul 2018 14:50:33 -0700

Excellent. Then all my comments have been addressed and I have nothing
further.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Jul 2018 11:11:26 -0400

On Tue, Jul 17, 2018 at 10:49 AM, John Levine <[email-masked]> wrote:

> Try this:
>
>  https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-
> rfc7601bis-02&url1=rfc7601
>
> Looks OK to me.  I have some minor editorial niggles about the wording
> of the EAI advice, but the substance is fine.
>
>
[re-adding [email-masked], removing [email-masked]]

What are they?  This is WGLC, now's the time.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 17 Jul 2018 11:18:00 -0400

>>  https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-rfc7601bis-02&url1=rfc7601
>>

In section 5:

For messages that are EAI-formatted messages, this test is done after
  	   converting A-labels into U-labels.

->

In authentication service identifiers in EAI-formatted messages, a U-label 
and its equivalent A-label are considered to be the same.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 29 Jul 2018 20:23:59 +0200

> .... and send comments to the DMARC working group mailing list by 3 August.

*Registries definitions*
Did the WG decide whether this document is going to update or obsolete rfc7601?
 IIRC, the catch was that obsoleting would require registries [re]definition
lest leaving pointers to obsolete defining documents.  Hm... perhaps it's fine
for a deprecated definition to point to an obsolete document... I'm not good at
that, I'm asking.

Anyway, I'd opt for obsoleting rfc7601 and copying in registry definitions as
needed.  The result is cleaner that way.  In addition, much of the text
(including the abstract) would need to be reworded if the doc /updates/ rfc7601.

*Domain based*
An introductory paragraph sounds outworn, since rfc7281 is not domain-based:

   This specification is not intended to be restricted to domain-based
   authentication schemes, but the existing schemes in that family have
   proven to be a good starting point for implementations.

*EAI addresses*
+1 for adding "or email addresses" in Section 1.5.2, Internationalized Email,
after the words "allow UTF-8 in most places that free-form text ".

*Section 1.2. "Trust Boundary"*
That section ends with two questionable statements about A-R fields found in an
attachment:

                        The details reported by this field cannot be
   trusted in that case.  Thus, this field found within one of those
   media types is typically ignored.

How about generic spam complaints and ARF reports of various kinds?  Of course,
trust in the report originator may vary, but I wouldn't say the field is
typically ignored.

*This proposal*
The term appears three times (sections 1.5.3. "Security", 7.11. "Reverse
Mapping", and Appendix A. "Legacy MUAs").  Won't the approved RFC be promoted
to "Internet Standard"?  In that case, I'd s/proposal/standard/.

*Section 1.6. "Trust Environment"*
The first paragraph deserves a reference to Section 5 "Removing Existing Header
Fields".

*authres-payload*
This rule is new.  Yet, the corresponding syntax doesn't seem to be changed; it
seems to be just a readability improvement.  Is that obvious?  If not, I'd
mention this change/non-change as a first entry in Appendix D, to reassure
parsers implementers.  Or am I misreading the ABNF?

*special-smtp-verb*
This rule is redundant and, if we're after readability, can be striked.  In
fact, both terms it produces fall under the "Keyword" rule.  In addition, IANA
reports smtp.rcptto as defined by rfc7293, so it can be omitted here.

*Keyword enumeration*
The note says:

   "Keyword" is defined in Section 4.1.2 of [SMTP].  When used in
   "result" above, it is further constrained by the necessity of being
   enumerated in Section 2.7.

I'd replace it with:

   "Keyword" is defined in Section 4.1.2 of [SMTP].  It is further constrained
   by the necessity of being registered in the relevant IANA Registry.  See
   Section 6.

Simpler and direct, no?

*prospec omission*
OLD:

   The "propspec" may be omitted if, for example, the method was unable
   to extract any properties to do its evaluation yet has a result to
   report.

NEW:

   The "propspec" may be omitted if the method was unable to extract or
   unwilling to disclose any properties involved in its evaluation, yet has a
   result to report.

*policy*
This ptype can now evolve from catchall to meaningful indicator:
OLD:

   A "ptype" value of "policy" indicates a policy decision about the
   message not specific to a property of the message that could be
   extracted.  See Section 2.4 for details.

NEW:

   A "ptype" value of "policy" indicates a policy decision about the
   method.  Its presence in a "resinfo" indicates that the algorithmic result
   of the method might have been overridden because of an internal criterion.
   Both "property" and "pvalue" concur at hinting what the internal criterion
   was.  See Section 2.4 for details.

The above interpretation is based on the example in Section 2.4, The "policy"
ptype, which reads:

      ... dkim=fail policy.dkim-rules=unsigned-subject ...

Now I'm not going to question whether policy ptypes should be registered,
always or sometimes, but since DKIM is quite liberal about what fields should
be signed, ptype/property pairs such as policy.dkim-signed and
policy.dkim-unsigned having a pvalue constrained to a (registered) header field
name could be more actionable than the above example.  It could be changed like so:

      ... dkim=policy policy.dkim-unsigned=subject ...

A consumer of DMARC forensic reports containing such field could extract the
field names and sum up how many receivers need which fields to be signed, for
postmasters to possibly amend their DKIM configurations.

Changing the result to "policy" matches Section 2.7.1. "DKIM and DomainKeys"
which sets "policy" as a possible result.  To say "dkim=fail" can be easier if
the desired effect is to steer a downstream filter.  However, the latter is a
hack which I wouldn't encourage.

Adding an augmenting example might also be useful:

      ... dkim=pass header.i=@ncas.us-cert.example policy.trust=yes ...

(In this case, the result is not overridden.)

Both examples are about DKIM.  Then, perhaps, the DMARC-styled example in
Section 2.7.1 ("For example, an ADMD policy [...] unacceptable even if they
verify") can be striked.

*Section 2.7. "Defined Methods and Result Values"*
s/New methods/Methods/

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 29 Jul 2018 19:49:30 -0400

On Tuesday, July 17, 2018 11:18:00 AM John R Levine wrote:
> >>  https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-rfc7601bis-02&url1=rf
> >>  c7601>> 

As an implementer (who's tried really hard to avoid spending cycles on EAI - 
sorry), does this translate into "be prepared for UTF-8 in any A-R element 
that may contain an email address or a domain"?

Scott K

---

From: "John Levine" <[email-masked]>
Date: 29 Jul 2018 20:13:56 -0400

>that may contain an email address or a domain"?

That's partly it.  IDN domain labels can be in two different forms, a
UTF-8 U-label or an xn--punycode A-label.  It would be a good idea to
treat them as equivalent.  There are translation libraries, and it's
easy to recognize U-labels by checking for the 0x80 bit so this is not
a lot of code.  Having been writing MTA patches to handle EAI better
last week, I say this from experience.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 29 Jul 2018 22:41:05 -0700

> last week, I say this from experience.

Does that mean the proposed change is appropriate, or the current text is
sufficient?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 29 Jul 2018 22:58:29 -0700

> for a deprecated definition to point to an obsolete document... I'm not

I thought it was pretty clear that this is a replacement, which means it
obsoletes 7601.

>    proven to be a good starting point for implementations.

 True, this can be removed.

*EAI addresses*
> after the words "allow UTF-8 in most places that free-form text ".

Deferring to the follow-up thread on this one.

> trust in the report originator may vary, but I wouldn't say the field is

Do you have a suggestion for alternative text?

*This proposal*
> to "Internet Standard"?  In that case, I'd s/proposal/standard/.

No, this is not being advanced to Internet Standard by this action.  It
could be, I suppose, but the WG hasn't discussed that question.

I'll change "proposal" to "specification".

> The first paragraph deserves a reference to Section 5 "Removing Existing

I kind of like how the various parts of Section 1 stand alone in terms of
laying out the ground work for what follows.  I'll change it if there's
consensus, however.

> parsers implementers.  Or am I misreading the ABNF?

It's meant to create a token that is easier for other documents (e.g., ARC)
to import.  I'll make an entry for it in Appendix D.

> reports smtp.rcptto as defined by rfc7293, so it can be omitted here.

It's not redundant.  MAILFROM and RCPTTO are not SMTP verbs.

*Keyword enumeration*
>    by the necessity of being registered in the relevant IANA Registry.  See

Not quite, because "Keyword" is used in four places, not just that one, and
when used as a "policy", its registration is not required because it only
means something locally.  But I see what you're getting and I'll fix it up.

*prospec omission*
>    unwilling to disclose any properties involved in its evaluation, yet

What's an example?

*policy*
>       ... dkim=fail policy.dkim-rules=unsigned-subject ...

I disagree, because I think the existing text still adequately captures
this case; there's been a policy decision made that was unrelated to some
value found in a header field or tag (i.e., it's not a straight "fail"),
but rather some combination of things that violates something the verifying
ADMD wants to enforce.

> *Section 2.7. "Defined Methods and Result Values"*

Why?  It's referring to methods that may come in the future, which I would
consider "new".

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 30 Jul 2018 11:40:57 -0400

> Does that mean the proposed change is appropriate, or the current text is

I still prefer my proposed change.  The way you handle A-labels and 
U-labels is an implementation detail.  Some convert everything to A, some 
convert everything to U, some have convoluted comparison routines.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 30 Jul 2018 14:55:40 -0700

> convert everything to U, some have convoluted comparison routines.

Ah, sorry, I hadn't seen your proposed change before.  LGTM.

-MSK

---

From: Tim Draegen <[email-masked]>
Date: Mon, 30 Jul 2018 18:35:52 -0400

To get an early start on shepherding the draft, I gave the draft a top-to-bottom review with an eye towards readability.

To ease the editor's burden, I'm avoiding posting a wall of diffs and have opted for sending changes directly to the editor for consideration. I'll leave it up to the editor to flag any changes that need may need discussion.

=- Tim

> On Jul 15, 2018, at 2:04 PM, Barry Leiba <[email-masked]> wrote:
>

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 31 Jul 2018 13:09:22 +0200

On Mon 30/Jul/2018 07:58:29 +0200 Murray S. Kucherawy wrote:
>> That section ends with two questionable statements about A-R fields found 
>> in an attachment:>>
>> How about generic spam complaints and ARF reports of various kinds?  Of 
>> course, trust in the report originator may vary, but I wouldn't say the
>> field is typically ignored.>

Say:

    In that case, if the producer intent is not to harm or mislead, the trust
    in this field's content would be proportional to the estimated quality of
    the producer's software.  Consumer's wisdom is key.

>> The first paragraph deserves a reference to Section 5 "Removing Existing 
>> Header Fields".>

IMHO, that paragraph was fine when the idea was new.  Nowadays it sounds
somewhat lengthy.  Referencing Section 5 might allow to shorten a little bit
the text.  It's just a question of taste, and since you're the author, it's up
to you.

>> fact, both terms it produces fall under the "Keyword" rule.  In addition, 
>> IANA reports smtp.rcptto as defined by rfc7293, so it can be omitted here.
>

Right, but their formation is well described in the relevant paragraphs, which
I quote:

   The list of commands eligible for use with the "smtp" ptype can be
   found in Section 4.1 of [SMTP].

   [...omitted paragraph here...]

   Where an SMTP command name is being reported as a "property", the
   agent generating the header field represents that command by
   converting it to lowercase and dropping any spaces (e.g., "MAIL FROM"
   becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.).

Please note that a dumb reader might fail to derive that the latter paragraph
is constrained by the former.  (Perhaps reordering and/or merging might help.)

In the ABNF too, the definition of special-smtp-verb doesn't constrain the rule
to the lowercase "smtp" ptype.  So, since the definitions of "mailfrom" and
"rcptto" can be found in their respective RFCs, 7208 and 7293, I fail to see
what's the added value of anticipating their definitions here.  To wit, you
could as well have defined, say:

     property = special-dkim-tag / special-smtp-verb / Keyword

     special-dkim-tag = "a" / "b" / "d" / "i"

     ...

Instead, you appropriately defer that until the DKIM section.

Just wondering...

>>    unwilling to disclose any properties involved in its evaluation, yet
>>    has a result to report.
> 
> What's an example?

This message is an example.  Unless removed, it bears a header field like:

    Authentication-Results: tana.it; auth=pass (details omitted)

It means I was SMTP-authenticated when I posted the message (otherwise it
wouldn't have been DKIM-signed.)  However, for obvious reasons, I don't want to
disclose the userid I authenticated with.

>> The above interpretation is based on the example in Section 2.4, The
>> "policy" ptype, which reads:
>>

Isn't that exactly the definition of policy?

   policy:  The message was signed, but some aspect of the signature or
      signatures was not acceptable to the ADMD.

> Why?  It's referring to methods that may come in the future, which I would

I thought the methods in Section 2.7.5. "Other Registered Codes" are not,
strictly speaking, /specified in this document/.  If the ID is meant to be
comprehensive —by definition or by reference— of all valid methods existing at
the time of publication, then the wording is fine.

Best
Ale

--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 31 Jul 2018 06:10:21 -0700

>     the producer's software.  Consumer's wisdom is key.

How is a receiver to know anything about the estimated quality of the
producer's software?

> is constrained by the former.  (Perhaps reordering and/or merging might

I'm not clear on how ordering helps here.  You need the two together
regardless of order.

I'm also not clear on what problem you're trying to solve.  Keep in mind
that this is now something like the fourth version of this document, and
this has not been identified as a deficiency in any prior version.  Is this
actually broken?

> disclose the userid I authenticated with.

I think that's operationally a poor choice.  The whole point of the data
that come after the pass/fail is to tell downstream agents what
identifier(s) might be of interest to record or highlight to users.  If you
managed to authenticate as the identity in the From: field, that's a lot
more interesting than if you authenticated as something unrelated; the fact
that the filter adding this left out that key piece of information almost
makes it useless.

But since the syntax (unfortunately) allows it, the proposed text change is
reasonable.

>       signatures was not acceptable to the ADMD.

Yes, so is there a need to restate all of that here?  That's all laid out
in Section 2.4.

-MSK