[ietf-smtp] my perspective: viewing SMTP specifications and practice thr

Rather than keep arguing with people over SMTP and IP address literals I 
thought I'd try to explain my perspective:
In the past few years I've been doing a lot of development of IIoT 
devices (/Industrial/ Internet of Things).   It's difficult to define 
exactly what this means, but it's fair to say that the assumptions that 
people have about the Internet of People (IoP) don't necessarily apply 
in the IIoT world.   I believe this should have implications for not 
only SMTP standards but also for other widely used standards like HTTP 
and TLS.   But I'll confine this discussion to SMTP.
SMTP is just a small part of the IIoT picture of course.   But in 
general IIoT uses Internet protocols in somewhat different ways than 
humans do, and may share some common implementations and infrastructure 
with Internet use by humans.   SMTP is of course very well established 
as a way to originate and relay email. Email is often used in the IIoT 
space as a means of having devices alert other devices, or people, of 
exceptional conditions.
My experience In industrial networking environments is that DNS is not 
universally supported, and use of IP addresses is quite common.   This 
makes more sense than it might seem at first. Most IIoT devices are not 
used by humans to communicate with arbitrary hosts, so they don't need 
to supply arbitrary names. Many IIoT devices have fairly fixed 
communications patterns, only communicating with only one host, or a 
select few hosts.   Many IIoT devices aren't easily configured.  Many 
don't have have human input or output devices.    So depending on what 
hardware is suited to the application, there may be pressure to keep 
configuration to an absolute minimum.   Also, DNS is often seen as a 
service that adds little or no value but does cause operational 
failures.   In a production environment, anything that halts production, 
causes additional delay in production, or impairs reporting of problems, 
is considered a business risk, with good reason.   Many but not all IIoT 
networks are completely disconnected from the public Internet, without 
even a NAT.   There may be very specific external hosts (specified by IP 
address, most likely via IPv4 address) that devices on a network are 
allowed to communicate with.  In some cases those external hosts will be 
public-facing SMTP servers.
For people accustomed to thinking about current and usual practice for 
the Internet of People, this may seem like heresy.
Of course, SMTP predates DNS, and was designed at a time when DNS didn't 
yet exist.   As originally defined, SMTP works fine without DNS, and 
most SMTP implementations probably still can be configured to work that 
way.   Even today, DNS is really only needed by MTAs that forward mail 
to arbitrary domains.
Not to single out any person in particular, but when people make blanket 
statements like "real MTAs use DNS names in EHLO" I see a red flag.   It 
strikes me as very common for people to assume that the use cases that 
they see most are "real", and that other use cases are "not real" or 
rare exceptions to the general case.   Use of IIoT devices is expanding 
rapidly, and we could soon see the number of IIoT devices in use rival, 
say, the number of PCs in use.
What I want is for future revisions to the SMTP specifications to 
facilitate operation of SMTP in a manner that makes sense for I*oT (not 
just IIoT) devices.  I have little fear that MTAs won't be configurable 
to support I*oT use cases, but I am concerned that the standards might 
prohibit configurations that make good sense for those use cases.   I 
don't think that IETF standards should silently presume that the 
protocols they define are only used for the IoP (unless the protocol is 
something that inherently requires human interaction), and I think it 
would be unfortunate if IETF standards explicitly limited their scope to 
the IoP.
Beyond use of IP address literals, similar considerations affect use of 
TLS with SMTP.   It doesn't make much sense to expect a server 
certificate to match a host name if the client doesn't know a host name 
to use, or the client isn't easily updated to know which server 
certificates to trust.   (Even firmware update is problematic in an 
environment where there is no connection to the public Internet and any 
upgrade is seen as a potential threat to operations.)   I have some 
ideas for how to use TLS in such an environment but they're not 
simple.   I don't think this problem can be dismissed, or solved by hand 
waving.
I'm not looking for any kind of immediate resolution to these issues, 
and suspect that many of them have to be resolved outside of ietf-smtp 
anyway.   Mostly what I'm saying is this:  Change has been a constant 
for the entire lifetime of the Internet, and the Internet continues to 
change.   Be careful about assuming that the Internet, or use of SMTP on 
the Internet, will or should stay the same.
Keith

p.s. I'm not terribly worried about how IETF runs its public-facing SMTP 
servers, because I assume that most inbound traffic for ietf.org is 
mailing list traffic.   I have no expectation that IETF will have a need 
to accept mail from I*oT devices.   I'm a bit more concerned about some 
of the arguments that have been made on the IETF list to the effect that 
the SMTP standard should change to conform to the practice of that 
single domain, despite the much greater depth and breadth of experience 
that informs RFC 5321.

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp