[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Remove mail in smarthost Exim queues sent from specific IP address

Dan Harris wrote:
I hope this is not a stupid question (I've spent several hours googling and
not come up with anything useful).

I work for an ISP and one of our customers has been reported to us for
sending Unsolicited Bulk Email via our smarthosts, which run Exim4. We've
disconnected the users DSL line so no more can be sent, but now we have the
problem of removing several thousand UBEs from the outbound exim queues,
when we only have a source IP address to go on. Is there an easy way to
achieve this?

I could be wrong here, but if all you have is the IP address of the sending server, then you'll probably have to grep through the queue files to get the exim message ids. Once you have a list of those ids, you can remove them.

Maybe a quick script to grep the *-H files in /var/spool/exim4/input for the IP address in question? The IP should be in the Received: header.

If you didn't know already, the file name of the queue files is the exim id of the message. For example:


The ones you're concerned with the are the ones in the input directory. The -D suffix is the 'data' file and -H suffix is the 'headers' file. So something like this might find the files and therefore the exim ids:

cd /var/spool/exim4
find -name "*-H" -print0 | xargs -0 grep -l BADIP | awk -F/ '{print $4}' | sed -e 's/-H//'

Also while I'm on the subject, what is the current thinking on preventing
this kind of abuse (accidental or otherwise)? We've looked into connection
throttling based on the number of emails sent, but is there a better way?

I haven't used it personally but I think the rate throttling feature in exim4 would probably work best in the case. I think you're only other option would be to scan incoming email from your customers for spam and that could get expensive resource-wise.


Michael F. Sprague     | mfs@saneinc.net
http://www.saneinc.net | Provider of SpamOnion anti-spam service
System and Network Engineering (SaNE), Inc

Reply to: