Re: [ietf-smtp] Endless debate on submission authentication

["John Levine" <[e-mail]>]

In article <[e-mail]> you write:
>On 1/2/2020 7:30 PM, Ned Freed wrote:
>>> 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 -

>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?

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