And this is an example of the main reason I would like to see
the proposal in I-D form. If the idea is unsuitable or not
worth the trouble for general use (as (as I surmised and John L.
and Michael seem to confirm) but useful for particular special
cases (as Phil suggests), being able to reform a draft with a
clear statement about applicability -- possibly including a
whitelist of permitted address ranges -- would be important.
Jeremy, I can't recall your posting an Internet Draft in the
past -- if you need a hand getting started, drop me a note
off-list.
best,
john
--On Sunday, September 2, 2018 01:16 -0400 Phil Pennock
<ietf-smtp-phil(_at_)spodhuis(_dot_)org> wrote:
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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp