[Top] [All Lists]

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

2019-12-23 04:28:05
Very good Keith. I agree with all your excellent engineering points. It should your post should be bookmarked as input for a "Mission/Application Statement" for any future RFC5321bis work.

I was thinking the last few days about client/server protocol modeling, like PPP, how we moved from binary to text-based protocol handshaking with FTP, SMTP, POP3, NNTP, IMAP, etc, and now with more wrappers and overhead layers with JSON, XML, TLS wrapping layers - huge overhead with a wider set of tools necessary to make it work.

But I was also thinking maybe we can do away with EHLO and replaced it with new CAPA like command. Or even perhaps the server can immediately issue capabilities upon connection: Wildcat! ESMTP Server v2020 ready
224-SIZE 102400000

And we really don't need to make it feature per line, it can comma delimiter or json can be used. This way we just get away from the how machine identifier/label waste and save a few protocol handshakes.

In all, imo, we got lost beginning with MARID in 2003. in the name of attempting to thwart spam and abuse and as result, we got into the "good enough" mode of thinking where even legit small people are hurt, but it doesn't matter. That is why I make distinctions between deterministic and nondeterministic concepts. We knew since day one the reverse-path was insecure and open to abuse, but we didn't do anything about it. I did with CBV but I would never advocate CBV in its current form as a light weight SMTP-based callback for standardization, but we can develop a fast, optimal CBV protocol as a strong SHOULD for all future receivers. I've been involved with Caller ID concepts since the modem days. The CID was normally issued after the 2nd ring and this concept naturally carried on with my internet migration. It was a no-brainer, to me, to perform a check for SMTP's reverse path that MUST be valid for bounce purposes at the moment it is presented. Its not a "maybe it will be valid later" concept.

The only way to do anything is with change and raising the bar. If the SDO is telling us ip-literals are no longer good, imo, it also raises the bar for everything else. Why isn't any input validated? Why isn't the reverse path not validated? Its all overhead I don't really care for, hence why when the client is authenticated, ALL of the wcSMTP validation overhead is preempted, skipped.


On 12/22/2019 6:13 PM, Keith Moore 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 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


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>