Folks,

A quick question on expected actions for milter return codes. My
intent is to have sendmail *drop* a connection immediately after the
connect callback. I have tried returning SMFIS_REJECT, but that
doesn't exactly cause the connection to drop. In fact it kind of
lingers a while, not that it is doing anything useful, but it is still
alive.

$ telnet localhost 16666
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
554 localhost ESMTP not accepting messages
HELO localhost
250 localhost Hello localhost.localdomain [127.0.0.1], pleased to meet
you
MAIL From:<nobody [at] example.com>
550 5.0.0 Command rejected
QUIT
221 2.0.0 localhost closing connection

So, how do I convince sendmail to drop the connection immediately? Is
there some config param that I have missed somewhere?

rnd

On Aug 14, 6:31 pm, qzr... [at] gmail.com wrote:
> Folks,
>
> A quick question on expected actions for milter return codes. My
> intent is to have sendmail *drop* a connection immediately after the
> connect callback. I have tried returning SMFIS_REJECT, but that
> doesn't exactly cause the connection to drop. In fact it kind of
> lingers a while, not that it is doing anything useful, but it is still
> alive.
>
> $ telnet localhost 16666
> Trying 127.0.0.1...
> Connected to localhost.localdomain (127.0.0.1).
> Escape character is '^]'.
> 554 localhost ESMTP not accepting messages
> HELO localhost
> 250 localhost Hello localhost.localdomain [127.0.0.1], pleased to meet
> you
> MAIL From:<nob... [at] example.com>
> 550 5.0.0 Command rejected
> QUIT
> 221 2.0.0 localhost closing connection
>
> So, how do I convince sendmail to drop the connection immediately? Is
> there some config param that I have missed somewhere?
>
> rnd

OK ...

After some spelunking in the 8.13.8 source tree, I have found
something that sounds like what I want to have happen:

[mfdef.h]
/* actions (replies) */
....
# define SMFIR_CONN_FAIL 'f' /* cause a connection failure
*/

Now this *really* sounds like what I want to have happen, however this
symbol isn't used/supported anywhere else in the tree. So, what
gives? Is this a pre-FFR kind of thing? Historic cruft? Sure would
be nice if it did what it purports to do!

Anybody able to shed some light on this?

rnd

In article <1187214889.784672.257170 [at] i38g2000prf.googlegroups.com>,
qzrrbz [at] gmail.com wrote:

> On Aug 14, 6:31 pm, qzr... [at] gmail.com wrote:
> > Folks,
> >
> > A quick question on expected actions for milter return codes. My
> > intent is to have sendmail *drop* a connection immediately after the
> > connect callback. I have tried returning SMFIS_REJECT, but that
> > doesn't exactly cause the connection to drop. In fact it kind of
> > lingers a while, not that it is doing anything useful, but it is still
> > alive.
> >
> > $ telnet localhost 16666
> > Trying 127.0.0.1...
> > Connected to localhost.localdomain (127.0.0.1).
> > Escape character is '^]'.
> > 554 localhost ESMTP not accepting messages
> > HELO localhost
> > 250 localhost Hello localhost.localdomain [127.0.0.1], pleased to meet
> > you
> > MAIL From:<nob... [at] example.com>
> > 550 5.0.0 Command rejected
> > QUIT
> > 221 2.0.0 localhost closing connection
> >
> > So, how do I convince sendmail to drop the connection immediately? Is
> > there some config param that I have missed somewhere?
> >
> > rnd
>
> OK ...
>
> After some spelunking in the 8.13.8 source tree, I have found
> something that sounds like what I want to have happen:
>
> [mfdef.h]
> /* actions (replies) */
> ...
> # define SMFIR_CONN_FAIL 'f' /* cause a connection failure
> */
>
> Now this *really* sounds like what I want to have happen, however this
> symbol isn't used/supported anywhere else in the tree. So, what
> gives? Is this a pre-FFR kind of thing? Historic cruft? Sure would
> be nice if it did what it purports to do!
>
> Anybody able to shed some light on this?

It's a risky thing to do. Dropped connections are supposed to be treated
by real SMTP senders as transient failures and that means they will
requeue the message and come back later.

--
Now where did I hide that website...

On Aug 16, 12:19 am, Bill Cole <b... [at] scconsult.com> wrote:
> In article <1187214889.784672.257... [at] i38g2000prf.googlegroups.com>,
>
>
>
>
>
> qzr... [at] gmail.com wrote:
> > On Aug 14, 6:31 pm, qzr... [at] gmail.com wrote:
> > > Folks,
>
> > > A quick question on expected actions for milter return codes. My
> > > intent is to have sendmail *drop* a connection immediately after the
> > > connect callback. I have tried returning SMFIS_REJECT, but that
> > > doesn't exactly cause the connection to drop. In fact it kind of
> > > lingers a while, not that it is doing anything useful, but it is still
> > > alive.
>
> > > $ telnet localhost 16666
> > > Trying 127.0.0.1...
> > > Connected to localhost.localdomain (127.0.0.1).
> > > Escape character is '^]'.
> > > 554 localhost ESMTP not accepting messages
> > > HELO localhost
> > > 250 localhost Hello localhost.localdomain [127.0.0.1], pleased to meet
> > > you
> > > MAIL From:<nob... [at] example.com>
> > > 550 5.0.0 Command rejected
> > > QUIT
> > > 221 2.0.0 localhost closing connection
>
> > > So, how do I convince sendmail to drop the connection immediately? Is
> > > there some config param that I have missed somewhere?
>
> > > rnd
>
> > OK ...
>
> > After some spelunking in the 8.13.8 source tree, I have found
> > something that sounds like what I want to have happen:
>
> > [mfdef.h]
> > /* actions (replies) */
> > ...
> > # define SMFIR_CONN_FAIL 'f' /* cause a connection failure
> > */
>
> > Now this *really* sounds like what I want to have happen, however this
> > symbol isn't used/supported anywhere else in the tree. So, what
> > gives? Is this a pre-FFR kind of thing? Historic cruft? Sure would
> > be nice if it did what it purports to do!
>
> > Anybody able to shed some light on this?
>
> It's a risky thing to do. Dropped connections are supposed to be treated
> by real SMTP senders as transient failures and that means they will
> requeue the message and come back later.
>
> --
> Now where did I hide that website...- Hide quoted text -
>
> - Show quoted text -

Actually, that's almost what I'd like them to do, especially as I'm
targetting botnet hosts... :-)

My surmise is that once I tank a botnet host, its smtp engine is lame
enough not to try again. I'm probably off base on this; chances are
that botnet v2 or whatever they're up to now has all the retry and
anti-greylisting stuff built right in... :-/

At any rate, I still haven't found a way to forcibly drop the
connection. Still looking for hints on that point.

rnd

qzrrbz [at] gmail.com wrote:

> At any rate, I still haven't found a way to forcibly drop the
> connection. Still looking for hints on that point.

I believe recent Sendmails will close the connection if the milter
sets the reply code to "421" (exactly that reply code).

I'm not sure if it only does it after HELO or at every stage of the
SMTP conversation; you'd have to test. I definitely see code
in Sendmail 8.14.1 to do this, though.

Regards,

David.