Subject: Re: [ietf-smtp] Endless debate on IP literals

From: "John R Levine" <[email-masked]>
Date: 1 Jan 2020 11:01:28 -0500

In article <[email-masked]>,
Dave Crocker  <[email-masked]> wrote:
>
>> With respect to all of the low performance IoT devices mailing out
>> status reports, that's submission, not SMTP.
>...
>> We definitely need to make it clear in 5321bis that submission and
>> SMTP are different
>+1
>
>Hence, Item 2 of the items list that I posted.

I think it's stronger than your item 2.  Even if your mail sending
setup does some MTA-like things, e.g., relay messages from somewhere
else, if it can't act like a fully capable MTA, it's doing submission
and needs to relay mail through a fully capable MTA.

I'm thinking, for example, of DMA (Dragonfly Mail Agent), a small
almost MTA that I use on my small server boxes.  Even though DMA can
technically do all the things that 5321 says an MTA is supposed to do,
I have it configured to relay everything to the submission server on
my real MTA rather than trying to send mail directly.

The definition of a fully capable MTA is circular -- it's an MTA that
does the things that persaude other MTAs that it's a real MTA.  There
are no doubt people who will find that unacceptably vague, but that's
life.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 1 Jan 2020 08:11:10 -0800

On 1/1/2020 8:01 AM, John R Levine wrote:
> does the things that persaude other MTAs that it's a real MTA.

We need to be able to point to a detailed, technical specification for 
'real MTA'.

What I'm less clear about is whether you are suggesting there be two 
classes of MTA -- I'll offer 'Enterprise MTA' vs. 'Public MTA' as 
possible label distinctions -- or whether you view these lesser MTAs as 
simply being MSAs.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Wed, 1 Jan 2020 08:22:03 -0800

> We need to be able to point to a detailed, technical specification for 

For the distinction John is raising, I assume that the text in

    Section 4.3.2.  Message Transfer Agent (MTA) of RFC 5598

    https://www.rfc-editor.org/rfc/rfc5598.html#section-4.3

is not sufficient.  Modifying it to support the distinction would 
represent the highest point of departure among RFC texts.

d/

---

From: Keith Moore <[email-masked]>
Date: Wed, 1 Jan 2020 11:30:25 -0500

> my real MTA rather than trying to send mail directly. 

I've been wondering if there's a need to talk about (for lack of a 
better term) "pre-submission relaying" which happens when a message is 
(for whatever reason) not initially submitted to a real submission 
server that does whatever sanity checking and fixup are needed to make 
the message suitable for relaying into the global email system.

The next thing I wonder is what port should be used for pre-submission 
relaying, or whether there should be a separate port for that, or 
whether there's a need for in-band signaling to tell an MTA which role 
it is supposed to play for a particular transaction.   (Somehow I don't 
think yet another port is a good idea, as I suspect that it just has the 
effect of giving people more confusing configuration choices to make).

But part of the notion of submission is to do all of that fixup in one 
place, so you don't have multiple MTAs in the signal chain mucking with 
the message.   It would be convenient if that fixup were unambiguously 
to be done at the first hop, but it seems that we might not have the 
luxury of being able to mandate that.   So to my mind the question then 
becomes, how do we unambiguously indicate where that fixup is to be 
done, so that it is only done once?

Keith

---

From: "John R Levine" <[email-masked]>
Date: 1 Jan 2020 12:19:42 -0500

>> We need to be able to point to a detailed, technical specification for 

It's somewhere between a profile and a BCP.  The profile would be of 5321 
or 5321bis, a set of commands and features it needs to support, e.g., 
EHLO with 8BITMIME and STARTTLS and PIPELINING.  The BCP is stuff like a 
fixed IP address with matching forward and reverse DNS that doesn't look 
generic, and that the MTA uses in its EHLO.

We obviously can't write down a set of rules and say if you do this 
everyone will accept your mail, but we can make it as likely as possible. 
I don't think we need to worry about large vs. small systems since 
everything I'm thinking of is easy to do on a $5/mo VPS or a Raspberry Pi 
in a school lab.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John Levine" <[email-masked]>
Date: 1 Jan 2020 13:38:45 -0500

>the message suitable for relaying into the global email system.

I don't see any need to tie ourselves into knots about this.  If you
want multiple submission hops before the real submission server, you
don't need to do anything special beyond ensuring that at each hop,
the server end has some way to limit who's relaying through it.  It
might be by IP range, or client authentication, or any of a variety of
other hacks invented over the years.  (POP-before-Submit, known in the
old days as POP-before-SMTP, comes to mind.)

My DMA submission servers do submision relay.  It works fine.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Wed, 1 Jan 2020 14:08:00 -0500

On 1/1/20 1:38 PM, John Levine wrote:

> In article<[email-masked]>  you write:

I agree that this isn't rocket science for anyone who really understands 
email, knows how to configure MTAs, and controls the entire signal path 
up to the submission server.    I also believe that most existing MTAs 
are perfectly capable of being configured to properly play any of these 
roles.

In my mind the question is: how to explain to ordinary operators, 
administrators, IoT device vendors, etc. how to make this work well?    
If someone is developing an IoT device that needs to send mail, what is 
that device required to do, what configuration options should it offer, 
etc.?   If an IT person in some enterprise is arranging for that 
enterprise's IoT devices to be able to send mail, what service do they 
need to provide, on what port, etc?   Does a submission service that's 
in the signal path for outgoing mail for such devices need any special 
configuration or considerations to be able to handle such mail?   (For 
example, does it need to be able to rewrite sender addresses containing 
IP address literals to make them globally meaningful while still being 
distinct from one another for different sender hosts?)   If the operator 
of the IoT devices can say to the enterprise IT person - I need an 
instance of service X, as defined by RFCYYYY, that might make things 
easier and reduce the amount of gratuitous meddling that people do with 
email.   Similarly if the developer of the IoT device knows exactly what 
the messages should look like and what service to interface to, that 
might make configuration of such devices either and reduce the chance 
that special measures will be needed for that device's email.

But I also have seen occasions on which even experts trying to do the 
right things, disagreed about how to do those things, in ways that 
caused problems when their systems interacted.   So I'm not sure that 
the standards are only for "ordinary" operators, etc.

Keith

p.s. I somehow doubt that we should recommend authentication based only 
on IP address at any level, though.    That's poor practice even for a 
small network that assigns static IP addresses to all of its hosts.   
More broadly there's a widespread misconception that isolated networks 
are not subject to security threats or that perimeter defenses are 
sufficient to protect them, even when such networks are used to manage 
critical infrastructure or equipment that can create hazards if not 
properly managed.

---

From: "John R Levine" <[email-masked]>
Date: 1 Jan 2020 14:34:16 -0500

On Wed, 1 Jan 2020, Keith Moore wrote:
> administrators, IoT device vendors, etc. how to make this work well?    If 
> someone is developing an IoT device that needs to send mail, what is that 
> device required to do, what configuration options should it offer, etc.?

A BCP for submission configuration advice wouldn't be a bad idea.  I don't 
think it needs to be very complicated but you're right that stuff that 
seems obvious to us is not to other people.  I don't know much about 
embedded environments but I think we could suggest some best practices, 
e.g., if the recipient needs the IP address of the sending device, put it 
in the message and don't depend on recovering it from the envelope or From 
header.

R's,
John

PS:

> p.s. I somehow doubt that we should recommend authentication based only on IP 
> address at any level, though.    That's poor practice even for a small 
> network that assigns static IP addresses to all of its hosts.   More broadly 
> there's a widespread misconception that isolated networks are not subject to 
> security threats or that perimeter defenses are sufficient to protect them,

It sounds like you may be conflating "authenticated" and "good".  The 
point of authenticating submissions is so that you know where they're 
coming from, and you're not an open relay for every random hostile host in 
the world, not that you know it's mail the recipient wants.  A device can 
be compromised or just have a bug and suddenly decide that it has 86,400 
overdue update messages it needs to send right now through its 100% 
authenticated submission channel.  That's why submission servers need 
sanity checks on the mail they handle.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 1 Jan 2020 14:38:16 -0500

On Wed, Jan 01, 2020 at 02:08:00PM -0500, Keith Moore wrote:

> administrators, IoT device vendors, etc. how to make this work
> well?    If someone is developing an IoT device that needs to send
> mail, what is that device required to do, what configuration options
> should it offer, etc.? 

Not much.  One of (configurable per site requirements):

1. Connect to port 25 on a configured IP and send email like it's the 90s.
   The local MSA will limit access to suitable IP ranges.

2. Connect to port 587, do STARTTLS and provide a configured username
   plus password to authenticate submission.  Much harder to support
   in low-end appliances, may need some managed trusted root CAs,
   NTP, ... unless OK to forgo authenticating the server in an
   isolated private network, but then see 1).

3. Same as 2, but implicit TLS over port 465.

> If an IT person in some enterprise is arranging for that enterprise's
> IoT devices to be able to send mail, what service do they need to
> provide, on what port, etc?

Quite possibly all of the above, although 1 is often sufficient.

> Does a submission service that's in the signal path for outgoing mail
> for such devices need any special configuration or considerations to
> be able to handle such mail? 

IP ACLs generally suffice.

> (For example, does it need to be able to rewrite sender addresses
> containing IP address literals to make them globally meaningful while
> still being distinct from one another for different sender hosts?)  

A configurable origin domain would be good, the default domain suffix
from DHCP is probably a good bet if nothing better is available.  No
"rewriting", just use a sensible default.

> If the operator of the IoT devices can say to the enterprise IT person
> - I need an instance of service X, as defined by RFCYYYY, that might
> make things easier and reduce the amount of gratuitous meddling that
> people do with email.

Nah, most operators don't read RFCs, TL;DR.  They google some How-To
guides, maybe skim the docs of their MTA, and glance at the IoT device
settings screen and figure out what's supported on both ends, making
tweaks until it works.

> Similarly if the developer of the IoT device knows exactly what the
> messages should look like and what service to interface to, that might
> make configuration of such devices either and reduce the chance that
> special measures will be needed for that device's email.

See above.

> the standards are only for "ordinary" operators, etc.

The experts may disagree on fancy features, but the basics remain
sufficient and unchanged.  See above.

> small network that assigns static IP addresses to all of its hosts.   

Well, authentication requires credential management, ... so means for
example devices joining Kerberos domains, or manually provisioned with
passwords, ... For which the standards are much more diverse than SMTP.
If you're concerned about the complexity of configuring SMTP, then you
really don't want to contemplate securing the network.

> critical infrastructure or equipment that can create hazards if not

It is not always a misconception, rather it can be a realistic
assessment that the cost of managing authentication may not be worth the
effort, and the barriers to get it working on specialized appliances are
quite high.

-- 
    Viktor.

---

From: Keith Moore <[email-masked]>
Date: Wed, 1 Jan 2020 14:47:47 -0500

On 1/1/20 2:34 PM, John R Levine wrote:

>
>> p.s. I somehow doubt that we should recommend authentication based 
>> only on IP address at any level, though.    That's poor practice even 
>> for a small network that assigns static IP addresses to all of its 
>> hosts.   More broadly there's a widespread misconception that 
>> isolated networks are not subject to security threats or that 
>> perimeter defenses are sufficient to protect them,
>
> coming from, and you're not an open relay for every random hostile 
> host in the world, not that you know it's mail the recipient wants.  A 
> device can be compromised or just have a bug and suddenly decide that 
> it has 86,400 overdue update messages it needs to send right now 
> through its 100% authenticated submission channel.  That's why 
> submission servers need sanity checks on the mail they handle.

I was specifically thinking two things:

(1) In general, it's a Bad Idea to promote source IP address checks as a 
form of authentication for anything - not because it's never good enough 
for any purpose at all, but because a lot of people won't do the threat 
analysis and/or impose additional measures (like switches that do 
address checking) to make it reliable even for the purpose they have in 
mind.   So "IP source address authentication is bad, mmmkay?" is 
probably more effective than trying to explain exactly under what 
conditions it might be marginally acceptable.

(2) It's cheap and trivially easy these days to build a tiny, stealthy 
device that static configs its source address, operates for hours or 
maybe days from a small battery, connects to local Ethernet or WiFi, and 
does whatever kind of disruption its creator wants - whether that's 
sending out faked messages that something's on fire, or sending malware 
to anywhere that the submission server will allow, or whatever.   There 
are lots of kinds of authentication, including challenge-response based 
on hashes of simple passwords, that I'd find perfectly acceptable in 
such an environment if managed correctly.   But even in such a 
relatively unsophisticated environment I don't think "authentication" 
based on anything that's exposed on the wire is good enough.   So no use 
of source IP addresses, no use of cleartext passwords, etc.

Keith

---

From: "John Levine" <[email-masked]>
Date: 1 Jan 2020 15:02:39 -0500

>effort, and the barriers to get it working on specialized appliances are

More than that, more complex authentication doesn't solve the problem,
since compromised devices can send authenticated spam.

If you're concerned about threats to and from IoT devices,
isn't that more what MUD addresses?

---

From: Keith Moore <[email-masked]>
Date: Wed, 1 Jan 2020 15:22:26 -0500

> since compromised devices can send authenticated spam.

There is no such thing as "the" problem.   There are only threats and 
countermeasures.

Compromised devices are one kind of threat; unauthorized devices 
introduced into the environment are a different kind of threat.

> isn't that more what MUD addresses?

You've heard of the concept of layered defense, I assume.

Also, I have no idea how much adoption of MUD there will be in these 
environments.   Not much, I expect, but it wouldn't bother me to be 
proven wrong.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 1 Jan 2020 17:00:45 -0500

>     The local MSA will limit access to suitable IP ranges.

Are we going to specify port 25 for pre-submission and only use 587 for 
"real" submission?   (and see another message about IP address 
authentication)

Not saying I like or dislike the idea - it strikes me that it might be 
the right answer but something still seems odd about it.

> 3. Same as 2, but implicit TLS over port 465.

TLS is somewhat problematic for various reasons.   For devices not 
connected to the public Internet, updates are harder, including updates 
to the list of trusted CAs (since old certs will have expired).   Also 
for machines that don't do DNS, TLS is still possible to use, but the 
client needs to know separately what name to use for certificate 
verification.   (Then again, last time I tried to write a HTTP client 
for a PIC32- only two years ago- the available TLS library didn't even 
have certificate verification support, in other words, it was nearly 
useless for security purposes.)

But I think challenge-response based on hashed passwords might be 
sufficient for purpose.

> "rewriting", just use a sensible default.

DHCP cannot be assumed.

On many occasions I've configured an SMTP relay for several small hosts 
to rewrite xxx@[ip-address] to [email-masked]

> settings screen and figure out what's supported on both ends, making

Yes, but RFCs do influence how-to guides, MTA documentation and 
configuration settings, and IoT device setting screens.

(I realize that a lot of operators basically try random things until 
something seems to work.   IMO we keep making the Internet dependent on 
experts who know enough about the protocols to have a fair chance at 
getting configuration settings right even when the configuration 
settings aren't very well-aligned with the protocol design.   But over 
time those experts tend to get replaced by people who don't have the 
same depth and only learn some magic spells.   I don't see that as good 
design, though of course I admit that expecting ordinary people to read 
RFCs isn't workable either.)

> sufficient and unchanged.

Disagree, but I'm not going to dive into that discussion.  Or maybe the 
"fancy features" are things that actually matter sometimes.

> really don't want to contemplate securing the network.

I see a need for authenticated submission even from isolated networks, 
and think that both IoT devices and submission servers (or 
pre-submission servers) need to support some of those, and need to know 
which ones to support.    Some of the existing SASL methods do appear to 
be suitable though.

> effort, and the barriers to get it working on specialized appliances are

I would relate some shocking discussions that I've had with developers 
of industrial equipment, but that would be exposing their customers to 
even more risk than they're already assuming by using those developers' 
products.

Keith

p.s. I suspect ietf-smtp doesn't want to dig down into details of how 
IoT devices should authenticate submissions - at least not just yet - 
and such a topic might be better discussed in a working group that's 
specifically tailored to that purpose.   For now I just want people to 
realize that some long-held assumptions may not be universlaly valid.

---

From: "John Levine" <[email-masked]>
Date: 1 Jan 2020 17:52:24 -0500

>realize that some long-held assumptions may not be universlaly valid.

On the contrary, I'd like to understand what we can and can't expect
them to do, and how they match up with the facilities we already have.

For example, CRAM-MD5 challenge authentication is widely available
give or take the issue that the server needs to store the password in
the clear.  If that's good enough, that's one less thing we need to
invent.

Also, some of the stuff you find confusing could go into a BCP, e.g.,
when to use port 25 vs port 587.  The main reason to do submission on
port 465 or 587 rather than 25 is that a lot of networks firewall port
25 as an effective anti-spam measure.  If you can be sure that your
network doesn't do that, at least for its internal traffic, port 25
submission works fine.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Wed, 1 Jan 2020 18:06:36 -0500

> them to do, and how they match up with the facilities we already have.

Ok, why don't I take a step back and try to summarize what I've seen 
about the limitations of such environments, and then we can look at how 
well existing SMTP implementations and protocol features address the 
needs of such environments.

(But not tonight, I've spent too much time on ietf-smtp today already.)

Keith

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 1 Jan 2020 22:35:59 -0500

> "real" submission?   (and see another message about IP address 

No, it is just one option.  The reasons I mention 25 are:

  - It is not uncommon to have port 587 MSAs refuse submission without
    TLS, and not all low-end devices support STARTTLS.

  - Some minimally configurable appliances only support port 25, with
    configuration limited to the relay hostname or IP address.

  - On private corporate networks, the internal mailhub may well not
    offer a separate port 587 service, it just runs a port 25 MSA,
    acting a smarthost for various null-clients.

  - TLS is definitely unavoidable with 465.  Therefore, for bare-bones
    SMTP without TLS, 25 may be a safer bet.  Port 465 has only recently
    been brought back from the dead, deployment is likely comparatively
    light.

> the right answer but something still seems odd about it.

Just a pragmatic choice.  A device that is capable of being a TLS client
should be configurable to use 587 and/or 465, but needs to also support
25.

> to the list of trusted CAs (since old certs will have expired).

Yes, another reason why 25 is a sound minimal default.

> Also for machines that don't do DNS, TLS is still possible to use, but
> the client needs to know separately what name to use for certificate
> verification.

Yes, that would need to be configurable, and perhaps also opportunistic
TLS without server authentication.  Which then leaves the question of
which SASL mechanisms to enable when the server connection is not
authenticated, but now we're into advanced features that I would not
expect IoT stacks to get right, unless they license a well designed
client SMTP stack.

> But I think challenge-response based on hashed passwords might be 

Yes, and if device passwords are not also the passwords to the owner's
bank account, social media, email, ... then having it stored on the
server may be OK, but I could mention in passing that a TLS client cert
could work, even if the server is not authenticated (again advanced
feature).

> > "rewriting", just use a sensible default.

Indeed, but it is one potential source of identity information for the
SMTP client.  Otherwise local configuration, or built-in defaults.

> to rewrite xxx@[ip-address] to [email-masked]

Best to work a domain name if at all possible.

> > Nah, most operators don't read RFCs, TL;DR.
> 

Mostly correct for MTA documentation, much less so for the how-to
guides from some random user on the Internet, and minimal designs
in low-end devices.

> "fancy features" are things that actually matter sometimes.

My point was that all you need is:

    * Connect
    * Wait for 2XX (possibly multi-line)
    * EHLO <client>
    * Wait for 2XX (possibly multi-line)
    * MAIL FROM:<sender>
    * Wait for 2XX (possibly multi-line)
    * RCPT TO:<recipient>
    * Wait for 2XX (possibly multi-line)
    * DATA
    * Wait for 3XX (possibly multi-line)
    * <body> (RFC5322, RFC2045, ...)
    .
    * Wait for 2XX (possibly multi-line)

which works on port 25 to a nearby suitably receptive smarthost.
Everything else is advanced features for clients that expect
more from SMTP than fire and forget submission.  Of course
things become more fun with EAI, PIPELINING, DSN, ... but
perhaps not for IIoT.

> which ones to support.

Operators often struggle with server-side SASL, IP ACLs are simpler and
less fragile for isolated networks.

> Some of the existing SASL methods do appear to be suitable though.

Password stores can be difficult to manage, and Cyrus SASL non-trivial
to configure.  Then you get nightmares like OAUTH...  Just "AUTH PLAIN"
is hard enough.

> realize that some long-held assumptions may not be universlaly valid.

The below are reasonably simple choices.

    * IP-based ACLs
    * AUTH PLAIN
    * Self-signed TLS client cert (if the MSA supports public key
      fingerprints, obviating the need for a PKI).

All the other choices are IMHO much too advanced for the average server
operator or SMTP client implementor.

-- 
    Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 2 Jan 2020 07:25:22 -0800

On 1/1/2020 9:19 AM, John R Levine wrote:
> It's somewhere between a profile and a BCP.  The profile would be of 
> 5321 or 5321bis, a set of commands and features it needs to support, 
> e.g., EHLO with 8BITMIME and STARTTLS and PIPELINING.

"Profile" turns out to have two, competing meanings.

There's a basic difference between creatinga larger, all-encompassing 
spec and then defining a subset that is useful, versus defining a small, 
common core and adding options to suit specific needs.

The former is what lots of classic 'profile' efforts do,notably from the 
telecom industry.  The base is complex and cumbersome, with the profile 
intended to define a streamlined, useful subset.  The latter is what the 
Internet work historically has done, though perhaps less so, recently.

What your second sentence, above, cites sounds more like the latter, 
which isn't a profile of 5321 per se, but rather is a combination of all 
of 5321 plus a set of additional options, made mandatory.  I assume the 
intent is something like a Exterior MTA Profile.(*)

The goal for 5321bis should be to make it as streamlined as possible, so 
that it defines a core, highly interoperable engine, that contains only 
the essentials, needed across all uses, and without touching topics that 
are extraneous to that core.  It's simpler to implement and use, and 
it's simpler to maintain the spec.

The current RFC has material that made sense to include in 1982. It 
arguably should have been removed from RFC 2821, but in any event is 
clearly out of scope now and that material is substantially out of step.

d/

ps. In distinguishing relaying within an enterprise from relaying across 
the open Internet, it finally occurred to me that we could replicate the 
language used for routing protocols and refer to Interior MTA and 
Exterior MTA...

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Jan 2020 11:48:39 -0500

> the message suitable for relaying into the global email system.

Interesting. A SMTP lint or MCA "Mail Compliancy Agent?"

   MTA <--> MCA
        --> MDA

The MTA connects to the MCA which can issue MCN (Mail Compliancy 
Notification) responses vis reply codes as an initial check. If 
positive, the MTA continues with the normal transport with a higher 
confidence all will work.  But what if the MCA doesn't match the 
target MDA checks, like at mail.ietf.org who will reject valid 
ip-literal usage?

Also, once MCA certification takes place, is it turn off, because it 
becomes redundant at that point.  It would be a nice idea for SMTP 
test site for new and updated MTAs.

Under wcSMTP and I believe across many other peer products, a "SMART 
HOST" concept is used. The profile and configuration in wcSMTP allows 
for sessions attributes:

- Profile Name: Target Email Domain
- required field: mail host domain
- optional field: port, default 25
- optional field: EHLO field, if blank, dynamic FQDN::IP-literal
- optional field: TLS Yes/No
- optional Field: ESMTP AUTH credentials

> it is supposed to play for a particular transaction.   (Somehow I
> don't think yet another port is a good idea, as I suspect that it just
> has the effect of giving people more confusing configuration choices
> to make).

No more ports please, :-) but you reminded me of another new 
legitimate section item for RFC5321bis:

- "Well-known" Protocol for MUA Configuration

https://tools.ietf.org/html/rfc8615

I did not use this, but I followed the Mozilla Thunderbird 
"well-known" setup for the next update of wcSMTP for auto-configuration:

https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat

> So to my mind the
> question then becomes, how do we unambiguously indicate where that
> fixup is to be done, so that it is only done once?

I see the "MCA" as an optional testing site.  It would be redundant 
once the kinks are worked out.

Some of us remember Fidonet, but back in the day, a new Fidonet 
installation node MUST have a valid compliant mail client/server 
frontend that following FTN1 specification before getting an address 
for the world-wide public nodelist.  Each local regional networks had 
a Network Hub who did the compliancy testing.

That would be equivalent to a domain registrar or ISP not giving you a 
DOMAIN or not allowed to get on the network or put the domain in DNS 
unless your SMTP installation supported the original protocol RFC788 
which predated RFC821.

I use to say it was the beginning of the demise when Fidonet 
Developers who were now working on X.25 and the coming IP world, were 
stuck supporting a primitive FTN1 (XMODEM based packet transfer 
protocol) when we now had text-based WAZOO client/server negotiating 
link phases.  That would be akin to having EHLO. If you didn't support 
it, you would not be allowed to send/receive mail.

Fortunately, the IETF did not go to this extent.

-- 
HLS

---

From: "John R Levine" <[email-masked]>
Date: 2 Jan 2020 12:03:09 -0500

On Thu, 2 Jan 2020, Dave Crocker wrote:
> The current RFC has material that made sense to include in 1982. It arguably 
> should have been removed from RFC 2821, but in any event is clearly out of 
> scope now and that material is substantially out of step.

Agreed.  I do think there's a few things like STARTTLS that need to move 
into the mandatory core, but not many.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Thu, 2 Jan 2020 10:07:01 -0800

> into the mandatory core, but not many.

To beat this point into the ground, just to make sure there is no 
confusion:  since starttls isn't in rfc5321...

The target documents would be:

    1) Astreamlined rfc5321bis

    2) A document specifying requirements for Exterior MTAs, which would 
include mandating rfc5321bis, starttls, ...

    3) Possibly a document specifying requirements for Interior MTAs?

My impression is that there's some amount of desire to restrict use of 
IP literals in EHLO [*] to interior mtas, and prohibiting them from 
exterior mtas.

If that assessment is roughly correct, it would mean that rfc5321bis 
would specify /only/ support for domain names in the EHLO command, with 
an Interior MTA document specifying an enhancement to the command, to 
allow use of IP literals.

d/

[*] whether and where to deprecate HELO is a separate issue needing 
similar consideration for scope of use.

---

From: Keith Moore <[email-masked]>
Date: Thu, 2 Jan 2020 14:10:48 -0500

>    1) Astreamlined rfc5321bis

yes.   But I don't think this is the place to impose policy, including 
policy about whether domain literals are permitted in EHLO/HELO.   I 
think this document should be targeted toward implementors of the 
protocol engines, with policy a separate layer (and probably in a 
separate document).   That way, implementors of the protocol engines 
have one clear and stable reference to work from.    Policy 
recommendations are less likely to be stable, as conditions will 
continue to change.   Putting policy recommendations in a separate 
document lets those recommendations evolve without affecting the base 
SMTP protocol specification.

So the SMTP protocol could permit IP address literals in EHLO/HELO as a 
matter of syntax, whereas policy could restrict that further.

>
>    2) A document specifying requirements for Exterior MTAs, which 
> would include mandating rfc5321bis, starttls, ...

I suspect the document needs to specify requirements for relaying across 
domain boundaries rather than talking about particular kinds of MTAs.  
I'm not sure that there is, in practice, a clean separation between 
Exterior MTAs and Interior MTAs, such that only Exterior MTAs are 
involved in relaying across domain boundaries.

Keith

---

From: Ned Freed <[email-masked]>
Date: Thu, 02 Jan 2020 19:27:49 -0800 (PST)

> network doesn't do that, at least for its internal traffic, port 25

And others have stringent security policies against mail being sent to any port
other than 25.

Getting hung up on which port does what isn't helpful. The goal should be
to figure out the actual characteristics of the services that are needed.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 02 Jan 2020 19:30:10 -0800 (PST)

> "real" submission?   (and see another message about IP address

I didn't think it was possible to do worse than the awful airport term
"pre-board" - which, as George Carlin noted, means to "get on before you get
on".

It seems I was wrong.

> the right answer but something still seems odd about it.

There's absolutely no question that SUBMIT, as presently defined is useless if
not actively inimical to a lot of IOT usage. But I don't think a precursor
step to SUBMIT is the answer, no matter what you call it. Rather, it's
a submission service with a different profile.

And I'm afraid everyone is going to have to accept authorization by IP as a
possibility, which, assertions to the contrary notwithstanding, scales just
fine to cover tens of thousands of nodes at a minimum.

> useless for security purposes.)

(I have no experience with the PIC32, but FWIW the situation with the ESP32 is
better than what you describe.)

But this walks around the bigger problem, which is handling
certificate/key/password rotations and updates at scale. The tools
I've seen for this so far fail to impress.

> But I think challenge-response based on hashed passwords might be

The idea of using an actual PAKE does have it's attractions, although the best
hash-only mechansism are probably sufficient. But there's still the password
management problem.

> configuration settings, and IoT device setting screens.

Exactly. This is why the business about removing support for IP literals from
"relay SMTP" worries me: It could easily lead to servers being written with the
capability removed entirely. So if you're going to do this, it needs to be done
in a separate profile document (or whatever you want to call it).

> RFCs isn't workable either.)

Very nicely put. I completely agree.

> > really don't want to contemplate securing the network.

And flipping it around: You're not going to come up with a competent service
profile without understanding cloud security mechanisms.

> which ones to support.    Some of the existing SASL methods do appear to

Agreed.

> realize that some long-held assumptions may not be universlaly valid.

IMO we don't have a choice if we're going to do this correctly.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 2 Jan 2020 20:19:11 -0800

> IMO we don't have a choice if we're going to do this correctly.

Knowing nothing about the specifics of this domain, I nonetheless find 
myself wondering...

For MIME, there was infinite debate about what character sets to support 
and how to support them.  After the protracted infinite debate reach 
asymptote, we punted and instead merely specified a place to specify 
whatever character set was being used and a registry for listing known sets.

Any chance a similar approach would be viable here?

d/

---

From: Keith Moore <[email-masked]>
Date: Thu, 2 Jan 2020 23:33:33 -0500

> "pre-board" - which, as George Carlin noted, means to "get on before 

(I always used to wonder about Dulles airport when they still used the 
"mobile lounges"... did you have to pre-pre-board those?)

> a submission service with a different profile.

Offhand, I think I'm fine with that.

> fine to cover tens of thousands of nodes at a minimum.
I never said it didn't scale.   I said it's too easy to defeat.   Or 
maybe the "submission service with a different profile" needs to do some 
serious rate limiting to keep it from being used to inject too many 
messages into the system.
> better than what you describe.)

I haven't wrestled with one of those yet.   (On the PIC32 project I gave 
up after a month and put everything on an ARM-linux platform, which 
brought with it a completely different set of security issues of course.)

> I've seen for this so far fail to impress.

My working assumption is that the larger number of IP appliances on 
industrial networks simply don't get updated, in any form, during their 
working lifetimes.    But it's hard to generalize because there are so 
many different industries with different ideas of standard practice.

> hash-only mechansism are probably sufficient. But there's still the 

Yes.

> in a separate profile document (or whatever you want to call it).

Agree.

> profile without understanding cloud security mechanisms.

Good point.   Because of course there's a widespread expectation that 
I*oT devices should talk to services in the cloud.  (I hope the "must 
use cloud" idea is a passing fad, it leads to a lot of shortsighted 
decisions.)

Keith

---

From: Dave Crocker <[email-masked]>
Date: Thu, 2 Jan 2020 20:36:56 -0800

> "mobile lounges"... did you have to pre-pre-board those?)

Actually, yes.  Whenever you thought you needed to get to the airport 
for your flight, you needed to get there an additional 30 minutes 
earlier, to catch the shuttle/lounge.

The mobile lounge was an impressively good example of a very good idea 
what totally didn't work as intended.

d/

---

From: Keith Moore <[email-masked]>
Date: Fri, 3 Jan 2020 01:09:44 -0500

> On Jan 3, 2020, at 12:43 AM, Ned Freed <[email-masked]> wrote:
> 
>>  If you can be sure that your

Well, we could recommend against such policies, and also recommend that devices use a different default port for submission.  But it’s probably the case that some sites will still find it easier to override the default and use port 25 than to get silly security policies changed.   

And I expect what that means is that a mail relayer can’t tell by the port used whether to act as an MSA or an MTA.  So sites might need to provision and configure separate services on different IP addresses.  That’s easier than it used to be with virtual machines being common now,  but could still run afoul of IT in many organizations.   Anyway I guess we just make the best recommendations we can with the knowledge that there will be deviations that equipment and software must be configurable to deal with.  Perhaps things will converge over time.

> to figure out the actual characteristics of the services that are needed.

Yeah it doesn’t matter which port but I do think it would help to further encourage a separation of function between submission and relaying.

Keith

---

From: "John R Levine" <[email-masked]>
Date: 3 Jan 2020 10:12:54 -0500

> And I expect what that means is that a mail relayer can’t tell by the 
> port used whether to act as an MSA or an MTA.

Huh?  Mail servers have been doing relay and submission on the same port 
for decades.  This is not an obscure situation or an unsolved problem.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 3 Jan 2020 11:51:50 -0500

>what totally didn't work as intended.

I'd flip it around -- the mobile lounges worked (still work) exactly
as intended, but the world changed underneath them.  When Dulles was
designed in the 1950s, air travel was mostly point to point, so the
passengers, dressed in natty suits and dresses, would take a leisurely
drive to the airport for their long flight and the trip on the mobile
lounge was a small part of the overall process.  Even so Dulles was
largely unused until long distance planes got too big for National and
in 1966 they limited National mostly to short-haul flights.

The mobile lounges really stopped being usable after deregulation when
there were a lot more flights and airlines went to hub-and-spoke
arrangements with most passengers making connections.  A connection
requiring two mobile lounge trips would be pretty painful.  The other
airport that depended on mobile lounges was Montreal Mirabel which
also had other problems, notably being an hour and a half from the
city without the promised high speed rail link.

Rather ironically, in Europe it remains common for planes, even large
long distance ones, to park at remote stands at the airport.  This is
exactly the situation mobile lounges were intended for, but instead,
you take a conventional bus and then run through the rain across the
tarmac and up the stairs to the plane.

There must be a moral for SMTP in here somewhere.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 3 Jan 2020 12:27:36 -0500

>Any chance a similar approach would be viable here?

I don't think so. For character sets at least you know where the text
goes.

We've been coming up with ways to authenticate submission for over 20
years.  The ones I can recall using are:

- static IP address (range or individual IP)

- indirectly authenticated IP address (POP-before-SMTP, for which I apologize)

- session SMTP AUTH, with various SASL schemes including PLAIN and CRAM-MD5

- session client certs via STARTTLS or port 465

I suppose we could have a registry of some sort, but POP-before-SMTP
and its ilk are pretty kludgy and I'm guessing other schemes would be
worse.

On the other hand, Ned says IP authentication is workable.  If I were
running an IoT system I would hope I'd have a database to track what
devices I expected to be on what IP addresses, from which it shouldn't
be too hard to extract a list of the ones that are expected to send
mail.  I realize NAT screws this up, but we can wave our hands and
assert that if you want to authenticate across a NAT, you need to use
something else.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 3 Jan 2020 13:03:29 -0500

>>what totally didn't work as intended.

Utterly irrelevant to mail, but see this quite charming cartoon
about by Charles and Ray Eames about the wonders of mobile lounges:

https://vimeo.com/4139559

---

From: Keith Moore <[email-masked]>
Date: Fri, 3 Jan 2020 13:45:11 -0500

> There must be a moral for SMTP in here somewhere.

They were an early example of store-and-forward.  :)

---

From: Dave Crocker <[email-masked]>
Date: Fri, 3 Jan 2020 11:02:41 -0800

> about by Charles and Ray Eames about the wonders of mobile lounges:

Wow.  I'd never seen that.  Besides being charming it does a nice job of 
giving an extensive bit of thoughtful analysis.

That it entirely missed the security requirements we now have isn't all 
that surprising, although it dramatically altered things in the main 
building.  More significant to me is that it missed the performance 
concerns over loading in a single, undifferentiated batch.

It turns out this is relevant to s/f networking, and the difference 
between switches that do output of a packet while still doing input of 
it -- giving delays measured in a small number of bit-times, versus ones 
that have to buffer the entire packet before being able to send it -- 
giving much larger delays, as well as needing substantial buffer storage...

d/