[Top] [All Lists]

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

2020-01-03 11:27:49
In article <9a7b77e2-2921-2fe9-273b-b944d27ae695(_at_)dcrocker(_dot_)net> you 
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

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

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.


ietf-smtp mailing list