Exim ACL help needed

EcoHosting

Member
Mar 6, 2004
23
0
151
Montreal
Hey Everyone,

Not sure if this is isolated or not but we have been receiving a deluge of forged emails bouncing off other servers. Is there some new virus out there causing this as it seems really sudden?

Here is the scenario: The emails are bouncing back to our server and being rejected because there is no such user. This is seriously hampering our servers capacity to process email in a timely manner. Spent a better part of the day cleaning up the queue. Thank the lord for Chirpy's Configserver Mail Queues, makes the task so amazingly easy (Thanks Chirpy!). The forged emails are concentrated on a few specific domains, I'd say about 80%. I'd like to add a function in Exim that would drop emails for non-existent users in these domains. I know this goes againts SMTP protocols but if I apply it to just the implicated domains I think I will be striking a relative balance between keeping my server functional and 'mostly' compliant.

So this is what I am thinking. I create a list of affected domains and drop anything that is not destined to an actual user. This would prevent my server from sending a return message to another non-existent user and clogging up my outgoing queue.

So I would need something to do the following:
a) read a list of affected domains
b) from this list of domain drop anything that does not have a verifiable user.

Can anyone help??

G
 

RickG

Well-Known Member
Feb 28, 2005
238
2
168
North Carolina
The emails are bouncing back to our server and being rejected because there is no such user. This is seriously hampering our servers capacity to process email in a timely manner. Spent a better part of the day cleaning up the queue.
Can you verify you are using :fail: for the default email account and not some catchall account? If the user does not exist, the messages should be rejected at the SMTP stage and never hit the mail queue.
 

gio_ecohosting

Registered
May 29, 2006
2
0
151
Yes we do have :fail: setup on all accounts. There is still an SMTP message sent back but since there is no actual recipient it ends up staying in our queue. This isn't normally a problem because it is at the SMTP level but when you get about 25,000 of them in about 8 hours then it has a serious impact on the server's performance. Our server's load during peak hours is between 4 and 8 but with this recent SPAM it jumps to about 20 and stays there all day.