Re: [ietf-smtp] Endless debate on IP literals
On 12/31/19 1:57 PM, John Levine wrote:
And while clients SHOULD use a DNS name in HELO/EHLO if they have one,
not all SMTP clients can be expected to have a DNS name. So servers
SHOULD NOT (maybe MUST NOT) reject mail based on the mere presence or
absence of an IP address literal in HELO/EHLO. It would be insane for
a standard to make a recommendation that degrades the reliability of the
service it provides.
I am reasonably sure that if we compare the number of MTAs sending
legit mail with numeric HELO to the number of spambots doing so, mail
reliability would be greatly improved by completely forbidding them.
I am starting to think that it's important to distinguish between
(a) SMTP the protocol, and
(b) The "globally-relevant Internet public email" service (GRIPE? [*])
that exchanges mail between otherwise-uncooperating [**] DNS-named
domains, routing mail by default using DNS MX, A, and/or AAAA records as
determined by lookup from the ICANN-specified roots, and exchanging mail
using SMTP-over-TCP over the public IPv4 or IPv6 Internet.
IMO the two have always been separate, even though the landscape has
changed over time and continues to change. And there are many
private-use networks (which might or might not be using private or local
address space) which use SMTP to exchange mail not only within
themselves but also with domains on the GRIPE service, and via the GRIPE
service to other private-use networks.
I believe the proper scope of 5321bis is the SMTP protocol, or at least,
that while the protocol and rules for transmission of mail within GRIPES
both need to be specified, they should be clearly separated. Offhand,
I suspect it's better if they're addressed in separate documents, but
that's just a guess at this point.
I think it makes sense to define rules for GRIPE that do not apply to
the use of SMTP in general. For example:
* all header and envelope addresses MUST be expressed in terms of DNS
names rather than IP literals;
* all participating nodes MUST have DNS names, which MUST be used in
* there MUST be PTR records linking clients' IP source addresses to
the DNS names that they use in EHLO;
* ESMTP MUST be supported by servers;
* HELO MUST NOT be used by clients and MAY be rejected by servers;
* all mail relayed via GRIPES MUST be subjected to certain sanity
checks and cleanup before such relaying,
* etc., etc.
I'm not necessarily arguing for any of these rules; I am not sure that I
agree with all of them. The point is that if you define a separate
service, you can make up rules for that service and also give GRIPE
servers advice about how to deal with mail that doesn't (yet) follow
those rules, independently of SMTP. And I think it makes sense to
raise the bar for GRIPE mail over time, and reduce the amount of
acceptable variation in email traffic, without having to revisit the
SMTP protocol specification, and without having to impose general
requirements on all SMTP servers. [***]
However, there will still be a need for private-use networks to be able
to relay mail through GRIPE, including to recipients on other
With respect to all of the low performance IoT devices mailing out
status reports, that's submission, not SMTP.
(It might be better to not speak of these as IoT devices, because IoT
seems to come with vastly different assumptions for different people.
But for now...)
To me this is at least a separate question. I don't think it makes
sense to insist that IoT devices submit mail directly to a submission
server that follows the rules for GRIPE, because (for example) the IoT
device might initially submit mail to a device which is also on an
isolated network, without DNS access, etc. So it might be that the
submission server that the IoT device uses, is not capable of meeting
It might make more sense to insist that the GRIPE rules apply whenever
mail is routed to a mail exchanger, i.e. via DNS lookup of the recipient
address domain. And a mail exchanger would be free to bounce or
pessimize mail that doesn't meet the GRIPE service requirements, ideally
after a predetermined grace period to give everyone time to implement them.
(I have some other questions regarding IoT use of mail submission
services, e.g. whether RFC8314 is suitable as-is for use on isolated IP
networks, or whether IoT devices should be required to use port 587 when
submitting mail so that the servers will know they have to treat such
traffic differently than message relaying. So there might need to be
a separate profile for mail submission on networks that don't have DNS
or connectivity to the public IP network.)
You point them at a
submission server that knows what network(s) the clients are on,
cleans up the messages, perhaps does some sanity checking so a rogue
lightbulb can't mailbomb people at qq.com, and forwards on the
messages as an MTA. A Raspberry Pi is overkill for this.
Well, maybe not. Some people see IoT networks as involving millions
(or even billions) of independent hosts and claim that their networks
and services are built for that kind of scale.
Happy new year, folks!
[*] Not a serious proposal for a name; I just wanted a shorthand
notation for it and that's what I came up with in a couple of minutes.
[**] If there's explicit cooperation between two or more mail domains,
they can make up their own rules for exchanging mail.
[***] Though I should probably point out that spammers will learn to
conform to GRIPE rules also. But in the long term I think it makes
sense for filters to rely more on content, on reliable indications as to
whether a message was forged, on authenticated sender identity and
perhaps sender reputation, and absence of protocol violations, than on
heuristics that don't really relate to any of the above in any strong or
enduring way. And GRIPE could also require signing, for instance.
ietf-smtp mailing list
|<Prev in Thread]
||[Next in Thread>|
- Re: [ietf-smtp] Possible cont4ibution to moving forward with RFC5321bis SMTP, (continued)
- Re: [ietf-smtp] Possible cont4ibution to moving forward with RFC5321bis SMTP, Hector Santos
- Re: [ietf-smtp] Possible cont4ibution to moving forward with RFC5321bis SMTP, Keith Moore
- Re: [ietf-smtp] Endless debate on IP literals, John Levine
- Re: [ietf-smtp] Endless debate on IP literals, Dave Crocker
- [ietf-smtp] It's not about IP-Literals, its about SMTP Compliancy., Hector Santos
- Re: [ietf-smtp] Endless debate on IP literals, John C Klensin
- Re: [ietf-smtp] Endless debate on IP literals, John R Levine
- Re: [ietf-smtp] Endless debate on IP literals, Dave Crocker
- Re: [ietf-smtp] Endless debate on IP literals,
Keith Moore <=