You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by ha...@t-online.de on 2005/11/20 18:10:09 UTC

Re: OT: Spammers' reactions to rejection

Hi,

I fear there are already more zombies than admins ...
It is a good idea to implement some kind of limiting, however, both on senders and receivers.
Some big ISPs dont take more than ## mails per hour from any other server, unless the other
one is a biggie too, or there is mutual agreement.
Limiting the number of simultaneous connections from any given sender is pure self defence
(at least for servers like qmail that limit the total number of incoming connections)

Senders may also choose to limit their outgoing mail, to cope with incoming restricions,
to limit the damage that can be caused by one of their customers getting hijacked, or simply
to be polite - it seems unfair for a sender that limits parallel incoming connections to create
many more outgoing connections than it would be willing to accept.

I believe these measures do not solve the problem of spam, however - they just make the
regular service run more smoothly.
Spam runs often tend to send many mails from one zombie, or a few ones, to accounts on
a single target server - by letting these few zombies run dry you dont reduce the load on the others.

Wolfgang Hamann

>> 
>> 
>> On Thu, 17 Nov 2005, mouss wrote:
>> > Roger Taranto a =E9crit :
>> >
>> >>=20
>> >> If it didn't tie up sockets on our machines, it seems like instead of
>> >> rejecting the mail, we should just hold on to the mail connection for as
>> >> long as possible.  It wouldn't take too long to tie up all of their
>> >> outbound connections and back up their mail server.  Unfortunately, it
>> >> punishes our mail servers, too. :(
>> >
>> > one way for that would be to "pass the descriptor" to a light process tha=
>> t=20
>> > will only keep them connected. for example setting the tcp window to zero=
>> =2E=20
>> > now, this would only be safe if you modify the tcp stack to do that witho=
>> ut=20
>> > keeping too much infos.
>> >
>> > On the other hand, they have so much bandwidth/power available via zombie=
>> s=20
>> > that this seems like playing a self-dos game.
>> 
>> Could this approach be effective if the number of such connections=20
>> were limited to a manageable number at any individual site, but it=20
>> was implemented by a great number of admins?
>> 
>> --=20