On Sun 15/Dec/2019 21:09:02 +0100 Keith Moore wrote:
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?
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
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
Right. Let's not forget that we also have a submission protocol. I think most
servers accept submissions on port 25 as well, providing per-IP authentication,
e.g. granting relay privileges to 127.0.0.1. That way, bare bones clients
won't actually distinguish SMTP from submission and will continue to work.
More generally, we should not assume that everybody uses Internet technology
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
or even most cases. We should keep that in mind when writing protocol
Agreed. However, an IETF public mailing list should be allowed to make some
assumptions about the kind of clients it allows. While syntactically
interchangeable, SMTP and submission protocols are semantically different. If
SMTP stated that message transactions should provide some form of
authentication —helo or sender names, DKIM, whatever— there wouldn't be
questions about why [192.0.2.1] is rejected.
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
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.
Consider a server who accepted an anonymous message from the disk driver, using
submission. It can deliver it to root, or it can relay it. In the latter case
it has to use SMTP. I think it may make sense to require the message to be
deanonymized even in this use case.
ietf-smtp mailing list