Jake Anderson wrote:
Yaknow it would probably be possible without too much difficulty to come
up with some sort of setup that listed the IP of the failed SMTP
connection and that could then be plugged into a firewall that would
just drop packets from those IPs. After 2 minutes after it started all
attacking IP's would be firewalled, bandwidth use would drop to
basically nothing, but Valid connections would still get through.
Obviously you would only deploy that system in a ddos situation but
still. It takes you from a "service" attack, where they try to break
your system by overloading a service, to just a bandwidth problem.
The SMTP connection does not fail in any way.
The described attack is more of a spam/virus attack, not targeted DDOS.
Some bot found a mailserver that accepts mail to any address and just
starts spamming in hopes that a few users will get the spam and probably
tells other machines to do the same. Maybe it thinks all aliases are
valid, in any case it doesn't care. It's not a DOS attack as such. It
will quit trying to spam you at some point when you start returning 550
to RCTP TO:. The content of these mails is usually spam and a virus payload.
I had this issue, when I forgot a to remove a catch-all alias in dbmail.
The problem was, that postfix delivered the mail to dspam, which created
virtual users for each mail (I use a different approach now), generated
a lot of load and those mails, that didn't get dropped by clam, were
delivered to dbmail. dbmail didn't have the users in the db obviously.
So all these mails were bounced, most of these of course never left my
MTA and clogged the queue.
IMHO, it should be made very clear in INSTALL, that the MTA must check
for valid recipients. Maybe it already is, haven't checked. :)
Alex
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
