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

[Keith Moore <[e-mail]>]

On 12/31/19 1:57 PM, John Levine wrote:

> In article <[e-mail]> you write:
>> 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 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!

Keith

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