Hello,

My ASL'd Centos5.5 (no ASL kernel) Plesk 10 server has recently been used to send spam out via an SMTP account with a poor password. This account had been used through Horde/IMP in the past to send out spam, and the password was changed, and the webmail disabled for the domain. I have a suspicion that there is a keystroke logger or other sort of monitor malware on the clients computer finding out their new info.

In any case, is there a way ASL can be beefed up to detect strange patterns in SMTP or webmail generated email? Or does it make sense to scan for spam email sent through an authenticated SMTP account?

Thats a though one, especially if the users come from dynamic IP space. You could use qmail-scanner to catch spam in outbound mail though

If you want to detect spam being sent from authenticated users then you would be better served scanning outgoing email for spam in general. Spamassassin does a wonderful job of discovering spam, so use qmail-scanner to do this. OTherwise, you're just duplicating something that already does the job perfectly.

Anyone that is scanning outgoing email on here? Like the results?

Sure, I'm scanning all in-and outgoing email. Sometimes you get a few false positives, but thats mainly people using a large html footer or signature and forgets to write a subject... They are normally in the LOW category spam though, so nothing is missing, just looks a little strange when the subject says spam.

We're using qmail-scanner as well. I don't believe there is a way to not scan outgoing e-mail when using qmail-scanner, right?

Not that I'm aware of...

is there anything with postfix?

In our case we setup a master mail relay server that runs windows with a custom smtp sink we wrote that integrates into comtouch for spam scoring and keeps track of which domains and which email accounts send how much and we use that to rate limit and throttle messages on a daily and hourly basis and just silenty drops bad email.

Im sure there is something equivalent in linux but we already had something similar for our mail servers that we just modified slighly for our hosting environment.

I recently contributed a patch to ART's qmail-scanner which doesn't scan outgoing e-mail if sent via port 587 (submission). It's in the stable channel now.

why would you not want to scan outgoing email?
Couldnt some one still use that for sending spam no matter what port its on?

Because it uses lots of resources and generates lots of false positives when your clients are on dial-up connections, etc. And some clients have huge mailinglists and scanning the same message for every recipient takes forever.



Submission (port 587) requires authentication, so qmail-scanner checks whether e-mail was sent via submission and then treats it as a message from a relay client (which it is) and skips scanning for that message. Only authenticated users can skip scanning outgoing messages. It's a great breakthrough for us, finally our users are able to use our SMTP servers again without getting flagged for being on a dial-up connection or other stupid reasons which are valid reasons for flagging incoming messages from other hosts, but not for messages from our own clients.

if some one has a script that sends through localhost (or w/e mail server) on 587 using smtp auth couldnt they have their script send out a bunch of spam, or run dark mailer or have some insecure script that some one else exploits to send a bunch of spam?

You need credentials to be able to send messages through port 587. If exploit code is already on localhost then it could just use the sendmail interface without the need for credentials, so I don't really see the problem of having another way to send out e-mail which is harder to exploit since it needs valid credentials.

In the case of large mailing lists if you detect that a user has submitted a large amount of messages in a short time period you can scan the first couple to make sure they are all basically the same thing (with out custom info like usernames, etc which will be different) by looking for a pattern and if the first email is good then you automaticlaly accept the rest if they match that same pattern as you know its not spam.

I personally think its not a good practice to allow email to be sent with out scanning it regardless of how it gets there and the best way to avoid customer impact is to accept the mail no matter what, queue it, and then send/offload the work is to have an upstream server that only does the scanning - but thats just my opinion.

I'm not trying to tell you how to run your server, Im just (badly) trying to make the point that no matter what port they are sending mail on and no matter how they get the mail there, they can still send spam or malware links, phishing emails, etc even if it requires credentials to do so.

Or for that matter when the smtp_auth accounts get compromised by bot nets, thats certainly a large source of the spam out there.