[Top] [All Lists]

[ietf-smtp] my perspective: viewing SMTP specifications and practice through an IIoT lens

2019-12-22 17:14:03
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.


p.s. I'm not terribly worried about how IETF runs its public-facing SMTP servers, because I assume that most inbound traffic for 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