[Top] [All Lists]

Re: [ietf-smtp] Endless debate on IP literals

2019-12-31 19:37:15
On 12/31/19 1:57 PM, John Levine wrote:

In article 
<fc8d4d71-39a4-6ca0-608a-d2113b206c5f(_at_)network-heretics(_dot_)com> you 
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
   EHLO ;
 * 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 private-use networks.

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 GRIPE requirements.

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, 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.   Suggestions welcome.

[**] 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