On Sun 15/Jul/2018 20:04:51 +0200 Barry Leiba wrote:
> 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.
*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 [email protected] 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
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
