Re: [ietf-smtp] Endless debate on IP literals
2020-01-01 13:08:17
On 1/1/20 1:38 PM, John Levine wrote:
In
article<482744ba-3a37-1fd8-48dd-0d8f58524abe(_at_)network-heretics(_dot_)com>
you write:
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.
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.
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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
|
|