For a couple of days now, my Debian/Exim4 mail server has become the target of a bunch of reprobates from Russia, who are slamming me with spam. Spamassassin is doing its bit, and my inbox is unaffected, but I have an issue with the amount of bandwidth they are eating.

The problem with Spamassassin is even if it rejects the spam, it still takes the whole message onboard, using up my valuable bandwidth. I would like to be able to set up something similar to the /etc/hosts_accept and /etc/hosts_deny file that I use to keep my ssh logons restricted, so that when a specific server tried to send to my server, I see the address at the start of the handshake and reject it without any further communication. Other servers should be able to access Exim unaffected.

I have seen something called /etc/mail/access.db mentioned, but I'm having problems finding out much about it...it *looks* like it may work, but I would like a HowTo if there is one around.... google is sulking at the moment otherwise I wouldn't ask

TIA
Jimbo

You could do it in iptables so your system rejects all traffic from the addresses your talking about instead of just mail. That way they don't even access the port.

Hi Jimbo,

Spamming bastards.

I have also been unable to find any information as it relates to access.db for Exim--everything I have found is for sendmail. If you are willing to try out other methods, I have some suggestions.

I also am running Exim and have implemented escalating measures against spam. I'm just ready to take the next step, but here are the measures that I have taken thus far:

1. SpamAssassin worked for a while, but there were too many false positives for my liking. Next step:

2. I disabled my catch-all account. Most of the spam that got delivered was not even addressed to me directly, but came to me because my mailbox took delivery of all otherwise non-routable addresses. Once I dumped that, spam dropped dramatically. To save on bandwidth, you will want to make sure that you fail non-existent addresses. If you send mail for non-routable addresses to /dev/null (aka "blackhole" it), then the SMTP sessions completes; to save on bandwidth, you need the session to abort before the DATA command. Even after doing this, there was still too much spam for me, so I took the next step:

3. I implemented sender callbacks. With sender callbacks, Exim pauses the SMTP session at the RCPT command, and checks that the envelope sender address is valid before allowing the DATA command to commence. Since most spam is sent from completely bogus addresses, this is very effective at cutting back on the amount of spam that gets through; and since the DATA command is never allowed, it saves on bandwidth. You should know that this might cause legitimate mail to be rejected: Exim uses the null sender <> in its MAIL_TO command to perform the callback, and some MTAs are not RFC-compliant and reject mail from the null sender, so that the callback will fail even when the mail is from a legitimate address. I have not personally had any problem with this.

After these measures, the spam I got was only from real addresses sent directly to my address. There was still too much, so took the next step:

4. I put my domain on a Barracuda antispam firewall. This essentially does the same as SpamAssassin, except it is not on my server and therefore not my bandwidth. There were a couple of issues; the largest was that some of my correspondents insist on forwarding emails as an attachment, which gets blocked as a potential virus. I added my domain to a unit that we have at my employer, so it was no cost to me and I was able to admin the unit and whitelist addresses that I knew were not spammers but from which legitimate mail was being blocked. This is probably not going to be an option for you, but it also had dramatic results.

From over 100 pieces of spam per day, only about 7 or 8 now make it to my server and get delivered to my inbox (I am no longer running SpamAssassin). A dramatic improvement, but I am going to take the next step. Most of the spam now getting delivered is bypassing the Barracuda. I have my MX record set to the Barracuda, and only a couple spam messages per day get through that. The rest of the spam that I receive is delivered directly to my domain's A record. So the next step I am going to implement is greylisting.

Greylisting, in a nutshell, involves recording a triplet consisting of the sender, recipient, and remote host IP address. The first time the triplet is seen, Exim will abort the session with a temporary failure message, so that the mail is delayed and the remote MTA will have to attempt to resend it. When it does resend it, Exim will see that the triplet is has already been recorded and will accept delivery. The idea here is that the vast majority of spam is not sent by legitimate MTAs that will retry in the event of a temporary failure; for the spammers' little programs, a temporary falure is the same as a permanent failure in most cases.

The end result of this is that the first time someone sends you a message that is relayed from a host with a given IP address, it is delayed and you will not receive it until the MTA attempts a redelivery. I have not yet done that, but was actually looking at the documentation on how to implement greylisting on Exim this morning before I saw your post.

Here are some links you might find useful.

About sender callback, including some caveats:
http://slett.net/spam-filtering-for-mx/smtpchecks.html

Exim implementation of callouts, including sender callback:
http://www.exim.org/exim-html-4.66/d...ssverification

greylisting in general:
http://projects.puremagic.com/greyli...hitepaper.html

greylisting for Exim:
http://www.greylisting.org/implementations/exim.shtml

The greylisting implementation that I am going to implement:
http://llab.zhitomir.net/?greylist

Good luck in fighting the good fight!

jlightner's iptables idea made me consider the possibility that the current spate of spam is from a limited number of IPs. If that is the case and you don't want to block them entirely from the server, but only from delivering mail, you could add an Exim ACL that drops sessions based on a blacklist of IP addresses. Here is a link for that:

http://www.maretmanu.org/homepage/in...am.html#sender

Some good and complete solutions there! Many thanks for the time taken to document the fixes, and the ideas provided. I had a look at http://www.maretmanu.org/ and implemented an ACL... I really must remember to RTFM before posting! However, there were several other ideas, methods and mechanisms that made asking a the question very worthwhile, so one again, Thanks Guys!

Jimbo