On Thu, Nov 30, 2006 at 01:14:09AM +0100, Randy Adamczyk wrote:
> tens of thousands of mailservers from all over the world in all kinds
> of ip ranges were bouncing spam mails to my server. most of the
> bounces i looked at were "no such user", "we don't accept spam", etc.
Ok this is typical for back scatter of a large spam run abusing your
domain.
> now, even the validrcptto patch didn't help! so even though all these
> spam-bounces were rejected immediately, all my concurrencyincoming
> session were used up, and no email could be delivered to the other
> domains on this server.
What could help a bit in situations like these is "close on error":
if ("" == mailfrom) and (notexists(rcptto))
send("551 no such user")
exit()
This has two effects:
1) the smtpds shut down a bit faster
2) bounces come in one in a connection, so for every bounce message
even the same server has to go back to the end of the queue. This
way you get a better turnaround and more mailserver with non-bounces
have a change to get into the queue of connecting servers.
> i don't think
> greylisting would have helped, either.
Not, it would have made it (a bit) worse:
1) each bounce would have needed two connections (the greylisted and the
one delivering the bounce)
2) all the connections would have come back because the bounces come
from mailservers
This is under the assumption that greylisting happens *after* the
validrcptto check. if it hapopens before the validrcpto check it would
have made it *really* worse.
> then i decided to change the mx record and point it to a new server
> so i can deal with the problem there, without affecting any other
> domains. already a few seconds later the attack moved to the new
> server, i was surprised it didn't take any longer.
As soon as the new MX is served by the primary DNS servers for that zone the
MX will be used by mailservers doing a fresh lookup. This isn't too
surprising ;-)
> plain lwq + djbdns, doublebounces and mails to unknown users go to
> /dev/null.
Accepting the message and sending it to /dev/null is worse than
rejecting it at the SMTP level with a 5xx error as response to the
RCPT TO command. Accepting the message takes some time during which the
smtpd slot is busy. After that qmail has to queue the message, schedule
it for local delivery, deliver it to /dev/null. This takes a lot of
useless CPU cycles.
> it came from all over the world, and i wouldn't really like to block
> entire countries either...
It's clear it came from all over the world. This was a back scatter
from legit mailservers and not fresh spam.
What *might* help in cases like that is publishing SPF records (although
I don't like the SPF concept in general). SPF enabled mailservers will
stop to accept mail from your domain not coming from IP ranges specified
in the SPF record. This is useful for blocking forged senders and joejobs.
This reduces the effect of back scatter.
\Maex
|