In article <9a7b77e2-2921-2fe9-273b-b944d27ae695(_at_)dcrocker(_dot_)net> 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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp