ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321

2020-09-27 10:24:09
Responding to the thread, rather than any specific note...

(1) We need to tread rather carefully here.  These checks are
closely connected to checks involving address-> name mappings as
well as name-> address ones.  SMTP did not anticipate single
clients sending from multiple interfaces/addresses, nor clusters
or clouds of machines sending out traffic without clear
discrimination about the actual sending host.  While the DNS has
mechanisms that, IMO, are quite adequate for associating
multiple addresses with the same host name, my anecdotal
experience suggests that reverse-mapping records with one
address and a long list of host names are quite rare.  SMTP also
did not anticipate clients (especially when ones communicating
with submission servers are ignored) running on addresses
(whether static or dynamic) assigned by ISPs rather than
regional registries.  Independent of clients who are part of
clouds and business arrangements large enough to push ISPs
around, many ISPs refuse to create reverse mapping records at
all [1] or will not create ones that that match client
perceptions of their names rather than server-location based
names following the ITU model [2]/

And that is even before we get to questions of gateways or NATs
between IPv6 and IPv4 systems.

So, without taking a position on whether we should make changes
in this area, they, and their implications, need to be thought
through very carefully.  We should also, IMO, try to preserve
the "if two, why not more" logic used when 2821 created an
explicit prefix model for IPv6 address literals rather than
simply assuming IPv4 and IPv6 literals could be distinguished
from each other by a simple heuristic test and that we would not
ever need to worry about, e.g., candidates for IPv7, IPv10, etc.

Also, a substantive note:  people decided (fwiw, over my
objections) to create a separate email list for the emailcore
effort.   With the very recent formal creation of that WG, I'm
not going to track proposed changes for the potential 5321bis
posted to this list (and hope that the WG Chairs will soon take
that responsibility off my hands).  So, if someone would like to
see changes, take them there.

     john




[1] As handy examples pulled from this thread, 68.166.206.83 and
64.147.123.25 apparently have no reverse mapping records at all.

[2] Highly informative (if you happen to be the ISP) reverse
mappings to things like
70.88.254-40-Lynn.MA.hfc.comcastbusiness.net are fairly common.
 

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp