Yes, that's the best strategy to fight spam. Otherwise if the email is already on your server, you have lost your precious BW to a spammer :angry:

One step to help fight spam at SMTP level is using qregex (http://www.unixpimps.org/software/qregex/) with qmail. Its working really great. I have blocked all my defunct email addresses that are now being used by spammers only :D

Anyone know if this is possible with exim? Share your strategies.

masood,

thanks for the link ! :)

for qmail tarpitting is one of the best methods coupled with rblsmtpd, IMHO

cheers
balaji

www.ordb.org
www.spamcop.net/bl.shtml
relays.osirusoft.com
www.dsbl.org
for example

spam assassin is apparently very good and it works with most major smtp daemons.

MotleyFool: You are welcome. I use tarpitting as well. But I havn't used the rblsmtpd, coz I think that might go a little over-board. I'll be trying it soon now.

taz0: thanks for the links. I have already bookmarked all of them :)

bacid: spam assassin works at smtp level? i think it tags the spam messages after they have been received?

we need to stop these spammers wasting our bandwidth :( so must reject all spam at smtp. since bounce can not work anyway!!

Originally posted by masood
we need to stop these spammers wasting our bandwidth :( so must reject all spam at smtp. since bounce can not work anyway!!

As a Web host, wouldn't your outgoing bandwidth utilization vastly outpace your incoming utilization? Given that circuits are typically full-duplex, and burstable charges are based on the peak in either direction, isn't your incoming bandwidth essentially free?

Of course, killing Spam is ideal, but for a Web host specifically, it's unclear why the incoming bandwidth matters. Kill the Spam whenever you can, I say.

Kevin

Originally posted by sigma


As a Web host, wouldn't your outgoing bandwidth utilization vastly outpace your incoming utilization? Given that circuits are typically full-duplex, and burstable charges are based on the peak in either direction, isn't your incoming bandwidth essentially free?

Of course, killing Spam is ideal, but for a Web host specifically, it's unclear why the incoming bandwidth matters. Kill the Spam whenever you can, I say.

Kevin


Only if they buy at 90/95th percentile, not per GB.

Yes Kevin you are right. It does not matter much as incoming traffic is like free, but it gives me "professional satisfaction" when the spammer's mail server can not deliver mail on my mail server :D

And I agree, kill the spam wherever and whenever you can!!

Originally posted by masood
Yes Kevin you are right. It does not matter much as incoming traffic is like free, but it gives me "professional satisfaction" when the spammer's mail server can not deliver mail on my mail server :D


OK, in that case, tar pit them :)

Kevin

Well,

Ok, now I'm doing similar setup in exim. I'm kinda stuck now and don't want to take risks on this production server. Any exim gurus here? :confused:

from FAQ:


Q0822: I'm looking for a rule to reject special unknown recipients.

A0822: If the messages in question are coming in via SMTP, you can turn on receiver_verify (if you haven't already) and arrange for these addresses not to verify. For example, if they are not in your local domains, you could use a router like this:


verify_check_specials:
driver = domainlist
condition = "\
${if eq {$local_part@$domain}{account@host.domain}{yes}{no}}"
verify_only
fail_verify
route_list = *


where of course you can extend the condition setting to use regular expressions, file lookups, Perl calls, or anything else that is available. The failure of the verification causes an error return to the SMTP RCPT command, so the messages never get into your system. For addresses in your local domains you could use a smartuser director in a similar fashion, but you could also use an alias file with :fail: entries.

If you are receiving such messages from the local host, then they are already in the system, and have to be failed locally as part of the delivery process. The :fail: mechanism is the simplest for local addresses. For remote addresses, one possibility would be to use a router with a condition setting to send such messages to an autoreply transport that sends back an error message to the sender.



Anyone understands this? I need to change it a bit for my situation :) I want to lookup at a file with unwanted addresses in it, and reject mail at SMTP RCPT command. :D