I've started using the dnsbl feature because doing a full spamassassin
scan on that many messages was eating my cpu alive. Now dnsbl is
working nicely (with the zen list), so I'm back to do some tweaking. Is
there some way I can introduce a delay of a few seconds before I give
the reject message after I get a hit on a blacklist? I don't want to do
a full-blown tarpit, but I figure slowing them down a bit couldn't hurt.
Is there a way to do that, without getting too deep into the guts of
sendmail? I'm running 8.13.6, on linux.

-Andy

Andy wrote:
> I've started using the dnsbl feature because doing a full spamassassin
> scan on that many messages was eating my cpu alive. Now dnsbl is
> working nicely (with the zen list), so I'm back to do some tweaking. Is
> there some way I can introduce a delay of a few seconds before I give
> the reject message after I get a hit on a blacklist? I don't want to do
> a full-blown tarpit, but I figure slowing them down a bit couldn't hurt.
> Is there a way to do that, without getting too deep into the guts of
> sendmail? I'm running 8.13.6, on linux.

You should be able to accomplish that with the BadRcptThrottle option.
Unfortunately, the sleep time is not configurable to my knowledge --
you'd have to tweak that in the source if desired.

-Bill

On 09/09/07 13:22, Bill wrote:
> You should be able to accomplish that with the BadRcptThrottle
> option. Unfortunately, the sleep time is not configurable to my
> knowledge -- you'd have to tweak that in the source if desired.

With a little bit of C hacking you can alter the sleep time. I altered
my server to have a liner progression of sleep time after
BadRcptThrottle. Thus NumBadcpt - BadRcptThrottle = ThrottleDelay for
each bad recipient. I also hacked the code to return a line of a multi
line reply once a second so that the remote server would not think that
the connection is just hanging out in la-la land. If you send me a LOT
of bad recipients it takes me a LONG time to return the multi line
message indicating that throttling is in effect before returning the
final line of the bad recipient message allowing you to send the next line.

If any one would like a copy of the hacked code, let me know. I'll try
to make a diff of the 8.13.8 source against my source.



Grant. . . .

* Grant Taylor wrote:
> On 09/09/07 13:22, Bill wrote:
>> You should be able to accomplish that with the BadRcptThrottle
>> option. Unfortunately, the sleep time is not configurable to my
>> knowledge -- you'd have to tweak that in the source if desired.
>
> With a little bit of C hacking you can alter the sleep time. I altered
> my server to have a liner progression of sleep time after
> BadRcptThrottle. Thus NumBadcpt - BadRcptThrottle = ThrottleDelay for
> each bad recipient. I also hacked the code to return a line of a multi
> line reply once a second so that the remote server would not think that
> the connection is just hanging out in la-la land. If you send me a LOT
> of bad recipients it takes me a LONG time to return the multi line
> message indicating that throttling is in effect before returning the
> final line of the bad recipient message allowing you to send the next line.
>

:-)

> If any one would like a copy of the hacked code, let me know. I'll try
> to make a diff of the 8.13.8 source against my source.
>

Sure, post it.

>
>
> Grant. . . .
>

On 09/09/07 20:20, NPG wrote:
> Sure, post it.

Ok, here goes. I'll post it in line and attach a small patch
too, hopefully one or the other will make it through and stay
in archives so that others can see what was done.

gtaylor:~/#diff srvrsmtp.c sendmail-8.13.8/sendmail/srvrsmtp.c
472d471
< volatile unsigned int tarpit_count = 0;
2434,2435c2433
< "BadRcptThrottle (%i) exceeded by %s",
< BadRcptThrottle,
---
> "%s: Possible SMTP RCPT flood, throttling.",
2443,2448c2441,2448
< for (tarpit_count = BadRcptThrottle; tarpit_count < n_badrcpts; tarpit_count++)
< {
< message("550-5.7.0 Too many bad recipients. Tar pitting is in effect.");
< (void) sm_io_flush(OutChannel, SM_TIME_DEFAULT);
< sleep(1);
< }
---
> /*
> ** Don't use exponential backoff for now.
> ** Some servers will open more connections
> ** and actually overload the receiver even
> ** more.
> */
>
> (void) sleep(1);

Let me know if you need / want any thing else.

By the way I have been running this code for multiple months with out any ill effect.



Grant. . . .
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: srvrsmtp.c.diff
Url: http://maillists.riverviewtech.net/p...attachment.ksh

On 09/10/07 01:56, Grant Taylor wrote:
> Ok, here goes. I'll post it in line and attach a small patch
> too, hopefully one or the other will make it through and stay
> in archives so that others can see what was done.

Eh, it looks like my email to news gateway stripped the attachment, but put it on the web for you to get. So, I'll leave it there for a while.



Grant. . . .

On Mon, 10 Sep 2007, Grant Taylor wrote:

>
> On 09/10/07 01:56, Grant Taylor wrote:
>> Ok, here goes. I'll post it in line and attach a small patch
>> too, hopefully one or the other will make it through and stay
>> in archives so that others can see what was done.
>
> Eh, it looks like my email to news gateway stripped the attachment, but put it on the web for you to get. So, I'll leave it there for a while.

Have you tried this agaisnt 8.14.x?
if it works maybe creat a proper patch by use of ' diff -Nau ' and submit
it for inclusion in official releases



>
>
>
> Grant. . . .
>
>

--

Cheers
Res

On 09/10/07 02:44, Res wrote:
> Have you tried this agaisnt 8.14.x?

(While looking down at the ground digging my toe in the dirt trying to
avoid the question...)

No, I've not moved up to 8.14.x yet. I've had other much more pressing
issues than to upgrade Sendmail and all my milters.

I know, shame on me.

> If it works maybe creat a proper patch by use of ' diff -Nau ' and
> submit it for inclusion in official releases.

Ok, I'll at least make a 'diff -Nau' patch and repost it for what I have
done and do the same when I do finally get up to 8.14.x.



Grant. . . .