We have started to recieve complaints that emails sent through our server bounce back with a failure message saying that it could not send to various addresses:
Hi. This is the qmail-send program at plesk2.expat-email.co.uk.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<frankwick@sbcglobal.net>:
Connected to 207.115.36.22 but sender was rejected.
Remote host said: 553 5.3.0 nlpi149 - o0M2f7SA026683, DNSBL:ATTRBL 521<
82.197.79.4 >_is_blocked.__For_information_see_http://att.net/blocks
<frankwheeler@sbcglobal.net>:
Connected to 207.115.21.20 but sender was rejected.
Remote host said: 553 5.3.0 flpi181 - o0M2f7P2015145, DNSBL:ATTRBL 521<
82.197.79.4 >_is_blocked.__For_information_see_http://att.net/blocks
<frankwhite2@aol.com>:
205.188.155.72 does not like recipient.
Remote host said: 550 MAILBOX NOT FOUND
Giving up on 205.188.155.72.
There are many more than this.
Access logs show no access to qmal from outside and qmhandle doesn't show any source other than our server being responsible for these failure notices. After checking the maillog there are no records of any attempt by qmail to send to these addresses.
It looks like we may have some trojan script or something sending these out.
Any ideas what could be going on and how to fix it?
Your best bet is to use the contact form that you'll find if you follow the link in the DFN.
Faris.
--------------------------------
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
I can't seem to find the reason we were blocked by AT&T anywhere. maybe I'm just being an idiot. It also appears to be the only place we are blacklisted and is apparently not always known for being particularly accurate. (Also listed on spambag apparently which has been down since 2007)
Have you got any suggestions for how to track if mails were being sent by perl?
Would a ps ax | egrep 'perl|pl' potentially come up with a cuplrit for example?
I'm afraid I don't have a huge amount of experience with this sort of thing.
The problem has now disappeared but without us finding the cause, the worry now is how to prevent it from happening again, and knowing what to do if it does.
* You can use firewall rules to restrict outbound connections (port 25) by userid.
* ASL has the client/server group capabilities to restrict what users can do, for example, services in the "server" group can only accept connections, and not send. "client" can only send, but not run a service, and nosocket can't do either. If you add a user to any of those groups, you will globally restrict what they can/can not do networking wise.
* We prototyped a transparent proxy server capable of intercepting and scanning outbound SMTP traffic, but option 1 is better - it will force mail thru your MTA, and not through a transparent proxy which will add more load to your system.
