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

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:
224-winserver.com Wildcat! ESMTP Server v2020 ready
224-SIZE 102400000
224-8BITMIME
224-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
224-AUTH=LOGIN
224 STARTTLS

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.
Thanks

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.
>
> 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
--
HLS


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