On 12/15/19 12:14 PM, Alessandro Vesely wrote:
On Sun 15/Dec/2019 17:13:38 +0100 Keith Moore wrote:
On 12/15/19 6:42 AM, Alessandro Vesely wrote:
If we reject [A.B.C.D], why don't we also reject foo.example?
The reason why SMTP requires to accept such stuff, AFAIUI, is to
allow a broken server to still be able to do its job. Is it so?
Compare that to, e.g., DANE, where a certificate error can shut a
server up.
IMO, hosts should not be required as a matter of SMTP protocol to use
DNS names, not even to send mail.
In a server to server connection, the HELO name can be used to provide
SPF authentication.
Don't assume that the mail is going to arbitrary destinations. In many
cases SMTP is used for status and error reporting. As long as the
devices sending such mail are sending it through relays that are
themselves trusted by the destinations of these messages (whether via
SPF or whatever other means), the system works.
More generally, we should not assume that everybody uses Internet
technology in the same way. The Internet (by which I mean all networks
using IP) is incredibly diverse and there is no usage scenario that is
representative of all or even most cases. We should keep that in mind
when writing protocol specifications.
DNS is simply a convenient way of finding IP addresses and allowing
applications to continue to operate across infrequent changes in IP
addresses.
To that end, host files would suffice. In addition to associating an
IP number to a name, DNS establishes a delegation hierarchy.
Even host files are not necessary in many use cases. Many useful
applications using IP do not need to use names at all.
It is not "a control plane for the Internet" (as some are now
saying), it is not a call setup protocol, and it is nowhere nearly
universal.
Hmm... not universal. However, the global Internet, given that you
spell it with a capital I, is, well, global. Multiple, non-global
DNSes were one of the doom future scenarios ISOC hypothesized a while
ago.
I still think there should only be one DNS root and one delegation tree.
(Which also means I think that two-faced DNS is a protocol and
architecture violation if it is used to provide lookups for names that
aren't delegated.)
There are very many IP networks that do not use DNS but which still
use SMTP to send mail, even if only to a forwarder. Before web
browsers were commonplace, many networks did not use DNS except to
forward email to the Internet. The popularity of web browsers has
resulted in much wider support for DNS, but there are still many
networks that aren't intended to support humans using web browsers.
For some of those networks, DNS is not a feature, it is a liability -
it adds nothing of value for them and is something that can break and
cause (say) assembly lines to fail.
In a walled garden it makes sense to accept mail from anyone who is
able to connect. To do so globally has proven to be unaffordable.
I agree with both of these statements.
It's important to understand that private, isolated, and intermittently
connected networks are all useful. "Walled garden" has somewhat of a
pejorative sense, as a way to lock in customers, but there are isolated
networks that aren't isolated for that reason. There are many useful
(often industrial) IP based networks that have no need for connect to
external networks, perhaps not even via NATs or application level
gateways. Those networks still use Internet protocols, and we do our
users a disservice if we don't consider their needs when writing and
updating our protocol standards.
Of course if an organization wants to refuse mail based on a MAIL FROM
address containing an IP address literal, it is free to do so. But
there is no particular reason I can see that an outgoing mail relay
needs to know its own DNS name, or even to have one.
The reason to have a name is that you can port it, along with your
reputation, across IP address changes.
That only matters if the devices using those forwarders to send mail,
use names as a means to learn how to connect to them. In many cases,
they do not use names, and should not be required to do so.
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp