On 2018-09-01 at 15:51 -0400, John Levine wrote:
Also, checking for clients that send HELO/EHLO before the greeting
remains a surprisingly effective way to recognize spambots.
How about for internal connections between a front-end mail-server which
does all the spam/malware filtering and a backend layer which handles
storage etc?
While I'm no longer a postmaster for a commercial service, I could see
it being useful to optimise the traffic flows there.
The same sorts of places where forward callouts can make sense. If
you're going to do forward callouts for verification, or even
cut-through delivery, then reducing the start-up overhead should make
life somewhat easier and reduce latency in a cut-through.
Because of exactly the concern you raise, I'd be hesitant to enable such
a feature directly facing most of the Internet, but would certainly set
it up within a cluster (not already using non-SMTP for internal
handling) and could see it as a useful thing for perimeter servers to
enable on a whitelist for connections from high-volume peers.
The round-trips are less of an issue for local services such as MLMs
injecting mail, but perhaps still interesting. It might also be an
interesting mode to enable for connections from localhosts, as various
senders which aren't fully SMTP-enabled could then just pipeline
everything. `cat | nc` becomes a potentially valid approach to send
mail on your own systems. That's not _bad_, though it's non-portable to
other environments.
Certainly makes it easier to set up monitoring probes which are designed
around the HTTP model, if they can just connect and send stuff and have
it work. Some of those don't really do expect-style interactions.
Whitelist your monitoring services and you're good to go.
-Phil
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp