draft-vesely-authmethod-dnswl has been presented to the ISE for
publication as an Informational RFC on the Independent Stream.
The document describes an email authentication method that has been
implemented by the Courier Mail Server and which might be seen in the
wild. The method defined is compliant with RFC 8601.
The document has been discussed in DMARC where most of the debate
focused on the assignment of the code points requested in Section 4.
The three registries touched all use the "expert review" assignment
policy, and this document has been shown to the relevant DEs and is
believed to meet the standards for assignment. Nevertheless, assignment
is subject to final confirmation by the DEs.
Along the way there was considerable discussion with the authors about
how this is *not* an IETF consensus document and therefore not an IETF
specification. The document now reflects that "this document is provided
for information".
A thorough review was provided by Alexey Melnikov (copied below) and the
document has been updated to reflect the discussions between the author
and Alexey.
The ISE also carried out reviews for clarity or purpose and to fix a
number of nits.
The document was updated four times during this process.
== Alexey Melnikov ==
I found this document to be useful addition to RFC series and support
its publication. I have a couple of minor comments:
In Section 2:
policy.txt: The TXT record, if any. Multiple records are
concatenated as usual. See Section 3 for the resulting
content and query options.
Please add a reference to an RFC with more details for novice readers
after "concatenated as usual". I only happen to know as I actually
needed to implement this a couple of months ago.
Also, it would be great if there is a field for reporting use of DNSSEC
when retrieving DNS TXT.
In Section 3:
According to [RFC5782], TXT records describe the reason why IP
addresses are listed in a DNSWL. The TXT record is useful if it
contains the domain name(s). The domain name would correspond to the
DNS domain name used by or within the ADMD operating the relevant
MTA, sometimes called the "organizational domain". In that case, the
authentication provided by this method is equivalent to a DKIM
signature ([RFC6376]) or an SPF check host ([RFC7208]). When no
domain names are known, some DNSWLs use a subdomain of .INVALID
You lost me here a bit, as I don't see a use case for this. Can you
maybe add an example showing use of .INVALID?
([RFC2606]) where the leftmost label hints at why an address is
whitelisted given that its operating organization is not known. If
the TXT record(s) contain non-ASCII characters, they need to be
encoded as appropriate.
The last sentence: can you explain what this means and possible add a
reference? Are you suggesting that UTF-8 should be allowed here? If yes,
say so (and add a reference). Or %-encoding (for example)?
== ISE ==
Section 1
OLD
The present method
NEW
The method described in this document
END
---
There are some abbreviations that need to be expanded on first use. I
see:
DNSxL
MTA
ADMD
---
Section 1
In order to smooth
operations, this document endorses a usage of TXT fields consistent
with other authentication methods.
I'm not sure abut "endorses". Maybe "describes"?
---
Section 2
In particular, some DNSBLs are known
to return special codes to signal over quota, for example
127.0.0.255.
Do you have a reference for that?
---
Section 3
s/domain name(s)/domain names/
---
A few places you use "IP" as short for "IP address". I think you should
spell it out. For example, Setion 3:
If no domain names can be responsibly associated
to a given IP, for example because the IP was added without direct
involvement of the organization concerned, DNSWLs can use a subdomain
of .INVALID ([RFC2606]) where the leftmost label hints at why an
address is whitelisted.
---
People are going to ask about IPv6. Do you have any thoughts?
---
Section 4 needs some work. We need to reduce it to a very precise
description of what we want IANA to do. So I think you could have...
4. IANA Considerations
IANA maintains the "Email Authentication Parameters" registry with
several subregistries. IANA is requested to make assignments as
set out in the following sections.
4.1. Email Authentication Methods
IANA is requested to create four new entries in the "Email
Authentication Methods" registry as follows.
Method|Definition|ptype |property| Value |Status|Version
------+----------+------+--------+-------------------+------+-------
dnswl |[This.I-D]|dns |zone | DNSWL publicly |active| 1
| | | | accessible query | |
| | | | root domain | |
dnswl |[This.I-D]|policy|ip | type A response |active| 1
| | | | received (or | |
| | | | comma-separated | |
| | | | list thereof) | |
dnswl |[This.I-D]|policy|txt | type TXT query |active| 1
| | | | response | |
dnswl |[This.I-D]|dns |sec | one of "yes" for |active| 1
| | | | DNSSEC | |
| | | | authenticated | |
| | | | data, "no" for | |
| | | | not signed, or | |
| | | | "na" for not | |
| | | | applicable | |
4.2. Email Authentication Property Type
IANA is requested to create a new entry in the "Email Authentication
Property Types" registry as follows.
ptype | Definition | Description
-------+------------+----------------------------------------------
dns | [This.I-D] | The property being reported belongs to the
| | Domain Name System
4.3. Email Authentication Result Names
IANA is requested to create four new entries in the "Email
Authentication Result Names" registry as follows.
Auth Method | Code | Specification | Status
---------------+-----------+-----------------------+--------
dnswl | pass | [This.I-D] | active
dnswl | none | [This.I-D] | active
dnswl | temperror | [This.I-D] | active
dnswl | permerror | [This.I-D] | active