I have a fresh new Cent OS 6.3 server running the latest Virtualmin 3.92.gpl with all the latest package updates (all’s been running wonderfully for a good month or so now!) I keep an eye on it with Logwatch (highest level of detail). Recently I saw something which really worried me, and try as I might to understand where the default Virtualmin Postfix configuration may be amiss (by reading the Postfix docs), I cannot see how this is happening.
I saw this line first thing this morning:
20 Sent via SMTP ---------------------------------------------------------------------------
1 kurdogluholding.com.tr
1 favorablyu98
The other 19 emails (not included in the details above) are ones I sent, but the one detailed above I most certainly did not send, yet it appears to have gone through. Which sounds as though my server may have sent on some spam, unbeknownst to me!
Is there something I’m missing in the default Postfix configuration that is allowing someone to send the odd piece of spam through my server? I use SSL with both incoming/outgoing mail and so my usernames/passwords have never gone across to the server unencrypted (and it’s just my domains on this server so no one else could’ve had their login details compromised).
Thanks for any input, I really appreciate it… the last thing I want is to be a vector for spam!!
It wouldn’t be possible for a non-authenticated user to relay email via your server on a default install.
The two most common ways that would happen are if a spammer broke into a web application on your server, and is sending spam via that application; or if one of your users has a PC that’s infected, and is sending spam via their PC.
You should be able to use your email logs in /var/log/maillog to determine roughly where the email came from – whether it was send locally, or whether someone connected remotely, authenticated, and then sent it.
Thanks so much for your response! I’m the only one connecting to this server, and I don’t think my Mac (latest OS X) is infected, as I use ClamXAV for protection, as well as running Little Snitch as a firewall to check any outgoing packets in detail. The only web apps installed on the server are up-to-date Wordpress installs.
Here are the related mail log lines, where I do see “status=sent” on the last one… I’m still getting accustomed to reading these logs, can you help me understand whether someone is connecting remotely or not from this information? And if so, what I might be able to do with my Postfix configuration to prevent their connections?
The key would be to see where the connection for those two emails came from… it’s showing there that the message ID’s for those two messages are 89E5D4C540D2 and 40CDA4C5415E.
What you’d want to do is look in your logs for the initial connection to Postfix for those ID’s, and see what the connecting IP address is.
Ah, thank you! I hadn’t realized I could look up those message ID’s in the logs (I hadn’t realized that’s what those keys were in fact). I now see what happened: there’s one email box on my server that forwards to an account at Gmail. Even with Spam Assassin deleting everything above a score of 10, occasionally a piece of spam comes in between 5 (the threshold) and 10 (flagged as such in the subject line)… these are often false positives, which is why I check them manually. But in this case, such a piece of spam (scoring between 5-10) was forwarded onto Gmail. It had an attachment that Gmail recognized as spam and rejected, bouncing the email back to my server as non-deliverable. My server then delivered the non-delivery notice on to that email address above in question (the alleged sender, but likely just some random email address the spammer picked).
I guess it would be nice not to have bounced that non-delivery notice on, but I don’t think there’s an easy way around it, as this was a potential rather than known piece of spam, and generally speaking I do want to know when outgoing messages bounce. It only became an issue with the forwarding to Gmail, which refused the message as spam even though my server accepted it; I won’t be needing that forward too much longer, so that should resolve the situation.
Thanks again for all your help… now I know how to troubleshoot this sort of thing properly myself! The key is in the mail logs and message IDs, of course
