Matthias Schmidt wrote:
> Happy New Year everyone :-)
>
> Am/On Tue, 1 Jan 2008 04:20:42 +0100 schrieb/wrote mouss:
>
>   
>> John D. Hardin wrote:
>>     
>>> On Mon, 31 Dec 2007, Mike Cisar wrote:
>>>
>>>   
>>>       
>>>> Even tried yanking the IP address off of the server over the
>>>> holidays in the hope that whatever it was would just give up.  No
>>>> such luck, within a minute of reactivating the IP to the server
>>>> this morning the traffic was back to full flow.
>>>>     
>>>>         
>>> Tarpit 'em.
>>>
>>> http://sourceforge.net/projects/labrea
>>>   
>>>       
>> Tarpitting may not be the right answer, because "they" have a lot more
>> resources than us (greetpause seems to work, if you use an asynchronous
>> server or proxy, i.e. one which can do other things while "sleeping").
>>
>> you can reduce the load by having your server drop the connection when
>> it rejects the mail, using 421 code.
>> depending on the server, it may be possible to do this at connection
>> time using zen.spamhaus.org (which lists many zombies).
>>
>> It may also be good to reduce the timeout when the server is under attack.
>>     
>
> but could this not also cause loosing legitimate email?
>   

the timeout must be reduced to a "reasonable" value. currently, most
MTAs implement "safe" values (RFC 2821 has some recommendations about
the minimum timeout at each stage), but today the internet is faster
than it was years ago. you can sniff legitimate traffic and see that it
is much faster than your current MTA timeout values.

> my server was also under attack 2 or 3 month ago.
> I tried the same thing as the op (listing ips in the fw etc), but these
> things didn't help at all.
>
> Most of the mails (>90%) were already dropped, because the ip didn't
> resolve (cannot find your hostname), the next 9.9% were caught by
> blacklists and only a very little number was rejected, because of
> unknown user name.
> One possibility might be to do the ip-check already through a hardware-
> firewall. 
>   

There is one issue here: Normal MTAs would retry if you don't reject
them "properly" by the MTA. some MTAs only understand few errors, and
you mostly need to reject them at RCPT TO stage. so one needs to drop
connections from zombies before they reach the MTA (using
zen.spamhaus.org for example), and reject other clients normally.

> But one actually can't do anything against the traffic coming to one's
> "indoor".
>
> best wishes to everybody (not to the spamsenders of course ;-) for 2008
>   

best wishes to everybody, even spam senders ;-p (but spam won't be
tolerated, even today!).

Reply via email to