[Top] [All Lists]

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

2019-12-23 22:16:07
On 12/23/19 10:29 PM, John C Klensin wrote:


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

Yes, at least regarding use of email by IIoT devices, I've been thinking along similar lines.   That's not to say that I want to throw away some of the improvements that have been made in the architecture of the email system, but I do want to think about how to make the IIoT use of email interact well with the mainstream use of email.

(IIoT security, by contrast, is an area where I believe existing "mainstream Internet" solutions are often a poor fit.)

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?

I have doubts about there being much interest in new use of SEND and friends.   A big part of the reason that customers like for IIoT devices to be able to send email is that such devices can plug into the existing and widely deployed Internet email infrastructure to deliver messages to people's desktops and phones.    While it wouldn't be hard to implement a SEND (or more likely SOML) command on an email gateway intended as an IIoT-to-something forwarder, my guess is that the most likely use of such a facility would be to gateway to SMS and similar protocols.   But there are lots of ways to do that - including existing email gateways of course - and it's not clear to me that SEND/SOML would be favored in the market.

Something I have seen the need for, however, is a service that will deliver a message immediately if possible, but which won't queue up the message for very long if immediate delivery is not possible.   Nobody wants to come back to work and find their mailbox full of messages from an IoT device because, say, the network was down for a time but the messages were queued up in the interim.   SMTP DELIVERBY is already defined of course, but I don't know how widely it is implemented.

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.

I share those concerns.   IoT (as opposed to IIoT) especially looks like a huge mess to me, because so many vendors seem to see it as a way to monetize surveillance, and also because the prevailing assumption seems to be that every device connects to a server "in the cloud" and interoperation between devices is sometimes seen as something that users can be made to pay extra for.   I keep hoping that a new architecture will emerge that is designed to protect users' privacy, but I'm not holding my breath.

But IIoT looks like an area where useful work can be done.     I also believe that there's potential for improvement in interpersonal Internet email.


ietf-smtp mailing list