[Top] [All Lists]

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

2019-12-23 21:29:22

After reading the rest of the thread up until a short time ago,
it seems most appropriate for me to respond to your original
posting in the thread.

From your description of IIoT requirements, they are not much
different from those of the many devices, some of them embedded,
that used email as a signaling, command, and logging mechanism
in the 1970s through the early 1990s.  In that context, we
should remember that, especially before we separated out
submission servers, SMTP (and maybe, to an even greater extent
822 -- I'll let Dave comment about that) was designed with
compatibility with, and smooth gatewaying from, systems that
might have no access to the public Internet and hence not to the
public DNS   To at least some extent, that suggests that some of
your concerns are less about a need for new features or re-tuned
rules but about remembering how we got here and that we should
not get so carried away with trying to match perceived majority
practices for for interpersonal communications that we prohibit
or discourage mechanisms that are needed for important, but
different, uses and applications.

In this regard, I agree with Dave's comments about nascent
efforts (but without wanting to get into a discussion of the
inflection points in various curves), but, at least from what
you've said, assume that the IIoT work you are doing may
actually rest on well-explored and tested history.

One question for you and others to think about given your
comments about IIoT: if email is used to alert other devices
about exceptional circumstances, maybe there are strong
arguments for the availability and use of SMTP SEND (even if not
SAML or SOML), with the lower overhead of not having to provide
822-based headers, maybe with some rethinking of at least some
trace fields, MX resolution, and relaying as properties
associated with the MAIL command but not of SMTP more generally
(and hence the un-deprecation of that command).   My experience
is very anecdotal, but dedicated (embedded or not) applications
needing signaling, etc., were the only good and long-term use I
ever saw for SEND.  I saw even fewer for SOML and SAML other
than creating a real-time "you have mail" mechanism as part of
the transmission protocol (even the 1983 version of Unix talk
was probably better).  Anyone prepared to make the case for
restoring and revision SEND?  

In the same light, if we were to get rid of relaying and
multiple MX records at different priorities, it would match de
factor contemporary practice among major mail providers and make
a whole series of security and privacy issues easier to think
about and get right.  Anyone ready to propose that?

And I'm glad that someone competent is worrying about security
in the IIoT spacs.  I fear that, in the IoT (and WoT) spaces, we
may end up with a lot of catching up to do that may turn out to
be even more painful than it has been for applications intended
to support communication among humans.


--On Sunday, December 22, 2019 18:13 -0500 Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:

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

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