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

From: Keith Moore <[email-masked]>
Date: Sun, 22 Dec 2019 18:13:46 -0500

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.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 22 Dec 2019 15:49:19 -0800

On 12/22/2019 3:13 PM, Keith Moore wrote:
> yet exist.

RFC 821:

> 3.7.  DOMAINS
> 
>       Domains are a recently introduced concept in the ARPA Internet
>       mail system.  The use of domains changes the address space from a
>       flat global space of simple character string host names to a
>       hierarchically structured rooted tree of global addresses. 

SMTP and the DNS were developed at the same time.  Work on SMTP (and RFC 
822) explicitly anticipated the DNS.

In any event, email -- using the FTP mail commands -- had already relied 
on use of hostnames -- ie, textual names -- for roughly a decade, 
independent of the means for mapping the name to the network address.

d/

ps. Email has been used for inter-process communications, of the sort 
you cite, also since the 1970s.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 22 Dec 2019 20:02:02 -0500

> On Dec 22, 2019, at 6:13 PM, Keith Moore <[email-masked]> wrote:
> 
> 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.

I share this concern, and hope that no message of mine inadvertently gave
the impression that I support removing support for features not used in a
one-size-fits-all model based on the public Internet (your IoP).

In Postfix, support for stand-alone and private network deployments is a
design requirement.  We also support TLS without a public PKI (based on
certificate fingerprints, explicit trusted signer keys, ...).   Raw public
keys on the server are not yet supported, because at present there's no
support for these in OpenSSL.  Otherwise, that'd be something I'd add
support for.

-- 
	Viktor.

---

From: Hector Santos <[email-masked]>
Date: Mon, 23 Dec 2019 05:27:38 -0500

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:
>
> 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.
>
> 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.
>
> 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
> 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.
>
> 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.
>
> 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
> 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.
>
> 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
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>

-- 
HLS

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Dec 2019 10:31:40 -0500

On 12/23/19 5:27 AM, Hector Santos wrote:

> with new CAPA like command.

This seems like a tremendously disruptive change with no real benefit 
that I see (at least not yet).    We've always been careful to make 
upgrades to the SMTP protocol backward-compatible because there are so 
many SMTP clients out there - not just in sheer number but also in 
number of distinct implementations.

(Now I'm curious as to how many SMTP transactions still use HELO, and 
how many SMTP servers are configured to reject it.   I'm also curious as 
to how much mail still gets initially submitted via port 25.)

> but it doesn't matter. 

Yeah, there's a rather flawed kind of thinking that has always bugged 
me, which is the belief that the volume of traffic is a proxy for the 
importance of traffic.   I have never liked the "good enough" reasoning 
for spam filtering criteria, but I also realized that spam was enough of 
an annoyance that people were going to do whatever they could to block 
it, even if a lot of valid mail got rejected.   I certainly didn't have 
a magic solution to propose at that time, and as best I recall there 
were so many people trying to insist that they had _the_ answer (often 
quite naively) that it seemed pointless to even try to keep up with the 
discussion.

Keith

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 23 Dec 2019 20:08:59 +0100

On Mon 23/Dec/2019 00:13:46 +0100 Keith Moore wrote:
> 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.
> 

I believe the sentence "real MTAs use DNS names in EHLO" refers to SMTP servers
when they act as clients.  Rfc5321 has a somewhat wider concept of MTA, so you
may claim an IIoT device is an MTA when it acts as a submission client.

Anyway, real SMTP clients use DNS.  I'd consider IIoT devices as submission
clients.  Consider this snippet of the draft standard:

   Many mail-sending clients exist, especially in conjunction with
   facilities that receive mail via POP3 or IMAP, that have limited
   capability to support some of the requirements of this specification,
   such as the ability to queue messages for subsequent delivery
   attempts.  For these clients, it is common practice to make private
   arrangements to send all messages to a single server for processing
   and subsequent distribution.  SMTP, as specified here, is not ideally
   suited for this role.  A standardized mail submission protocol has
   been developed that is gradually superseding practices based on SMTP
   (see RFC 4409 [18]).  In any event, because these arrangements are
   private and fall outside the scope of this specification, they are
   not described here.
                      https://tools.ietf.org/html/rfc5321#section-3.6.3

Best
Ale
--

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Dec 2019 15:03:16 -0500

On 12/23/19 2:08 PM, Alessandro Vesely wrote:

> clients.

Color me skeptical.   From an idealist perspective I would like such 
devices to submit mail to MSAs using port 587, or better, TLS over port 
465.   I'm just not sure that will fly as there seems to be a lot of 
mindshare in that world around submitting mail using port 25.   More 
generally, there's a lot of preference for using as little configuration 
as possible, especially per-device configuration.

But I'd probably support recommendations for IIoT clients to use 587 or 
465 with authentication, especially if TLS could be profiled in such a 
way as to permit the authenticated party to be the client end rather 
than the server end.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Dec 2019 12:06:04 -0800

On 12/23/2019 12:03 PM, Keith Moore wrote:
>  From an idealist perspective I would like such devices to submit mail 
> to MSAs using port 587, or better, TLS over port 465.   I'm just not 
> sure that will fly as there seems to be a lot of mindshare in that world 
> around submitting mail using port 25.   More generally, there's a lot of 
> preference for using as little configuration as possible, especially 
> per-device configuration.

It's fairly common for nascent efforts to seek ways to simplify their 
work and operation, on the claim that they have a simpler environment 
and won't (ever) need the additional mechanisms.  In those early days, 
the appeal of the simplifications is understandably strong and even 
seems reasonable, within their immediate framework.  However their 
assessment of the future is almost always wrong.

d/

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Dec 2019 15:23:23 -0500

On 12/23/19 3:06 PM, Dave Crocker wrote:

>>  From an idealist perspective I would like such devices to submit 
>> mail to MSAs using port 587, or better, TLS over port 465.   I'm just 
>> not sure that will fly as there seems to be a lot of mindshare in 
>> that world around submitting mail using port 25.   More generally, 
>> there's a lot of preference for using as little configuration as 
>> possible, especially per-device configuration.
>

These people do not see their efforts as "nascent".    Devices like 
these have existed for decades.  Though they're starting to become much 
more common, due both to the increasing capability of low-cost hardware 
(think raspberry pi, beaglebone, etc) and the Linux ecosystem with all 
of the code available for reuse.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Dec 2019 13:13:35 -0800

On 12/23/2019 12:23 PM, Keith Moore wrote:
> these have existed for decades.

Network effects.  Things are nascent until they his the real knee of the 
curve on scaling.(*)  That's only just starting to happen.

d/

(*) The Internet work went about 25 years before hitting its scaling 
knee.  However it had the unusual benefit of people worrying about 
scaling long before that.  Even so, it is often criticized for not 
having considering scaling well enough in that time...

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Dec 2019 16:35:16 -0500

On 12/23/19 4:13 PM, Dave Crocker wrote:

> Network effects.  Things are nascent until they his the real knee of 
> the curve on scaling.(*)  That's only just starting to happen.

Sure.   But there's a lot of inertia, and some justification, behind 
their operational practice and expectations.   Treating them as if 
they're newbies probably won't work well.

FWIW, the biggest concerns I have about that world aren't about email, 
they're about security.    But I'm becoming sensitive to just how often 
the assumptions of the "mainstream Internet" world clash with those in 
the IIoT world, and also why the practices and solutions from the former 
don't always work in the latter.

Keith

---

From: John C Klensin <[email-masked]>
Date: Mon, 23 Dec 2019 22:29:00 -0500

Keith,

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.

best,
   john

--On Sunday, December 22, 2019 18:13 -0500 Keith Moore
<[email-masked]> 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
> 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
> 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
> 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
> 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.
> 
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Dec 2019 23:15:51 -0500

On 12/23/19 10:29 PM, John C Klensin wrote:

> in the 1970s through the early 1990s.  [...]
> To at least some extent, that suggests that some of

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

> 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

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.

Ketih

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 24 Dec 2019 10:29:32 +0100

On Mon 23/Dec/2019 21:03:16 +0100 Keith Moore wrote:
> Color me skeptical.   From an idealist perspective I would like such devices to
> submit mail to MSAs using port 587, or better, TLS over port 465.   I'm just
> not sure that will fly as there seems to be a lot of mindshare in that world
> around submitting mail using port 25.

Serving submission on port 25 is a feasible alternative:

   Although most email clients and servers can be configured to use port
   587 instead of 25, there are cases where this is not possible or
   convenient.  A site MAY choose to use port 25 for message submission
   by designating some hosts to be MSAs and others to be MTAs.
                         https://tools.ietf.org/html/rfc6409#section-3.1

Best
Ale
--