Client sending emails, but not showing their account as sender

[GoWilkes]

This is for a shared server that I maintain. One of the accounts has recently been sending a high number of emails, and under the "Relayers" list, it shows a different account as the sender.

For example, assume that their domain is example.com, the Relayers list shows:

Sender: [email protected]
Destination: [email protected]

Nacha.org has a warning on their site about phishing emails, so I don't feel bad about showing their name here. It's not their fault; someone is just spoofing them as the sender.

Regardless, an account that usually sends 30-40 emails a day is now sending 800, so I'm sure that there's a virus on their end, somewhere.

The question is, how do I prevent their account from sending emails that do not list their domain as the sender? I tried adding an SPF filter, but I'm not sure if this will do it. To do so, I added this to their DNS zone:

example.com.
14400
IN TXT
"v=spf1 a mx -all"

Is this going to do what I want? I assume that, since there was no TXT item here before, then I won't find out for 14,400 seconds if it worked. If not, what can I do to prevent it, while waiting on the client to fix their virus?

 

[minosjl]

Enable the MailHeaders using easyapache and check the mail header, to find out is there any script is using for relaying.

 

[ruzbehraja]

It seems an accounts password has been compromised (virus), more than a script in their account.

Have you enabled SMTP Authentication for email sending?
You can check that from WHM >> Tweak Settings >> Prevent “nobody” from sending mail.

You should have this enabled.

If SMTP Authentication is already enabled i.e. the nobody user cannot send out mail, then you need to check the mail queue to see which users password is being used to send out the mail.

I guess that there will be some mails in the mail queue.

Open up a mail which is in the queue. You should see something like this:

1Ra30I-00069a-6W-H
mailnull 47 12
<[email protected]>
1323685262 0
-helo_name server
-host_address 111.117.112.10.4573
-host_auth dovecot_login
-interface_address zzz.zzz.zzz.zzz
-received_protocol esmtpa
-body_linecount 1172
-max_received_linelength 75
-auth_id [email protected]

You need to identify the line -auth id and check the email id mentioned in it.
This is the email id that was compromised.

Your problem will be solved if you change the password of this email id and ask the client to take responsibility for cleaning up their local machines. (or they can temporarily use webmail till they are sure about it)

Do post the outcome.

 

[GoWilkes]

Sorry for the delay in replying. For some reason, I just now got the email that you had replied.

In this case, the problem was a virus on an email account holder's computer, so their email program was actually sending out the emails, using a legitimate username and password. So, disallowing "nobody" had no impact; if the email account holder could send an email, then so could the virus.

I was able to track it down by blocking all spoofed emails, then finding the errors in the mail statistics. More on that here:

http://forums.cpanel.net/f5/tracking-down-email-account-virus-247802.html

That worked conclusively, but I believe your suggestion would have been considerably easier!

Once I found it, changing the password until the client fixed it on their end did work.

Unfortunately for me, Senderbase.org now gives my server a "Poor" reputation, which is rather undeserved in my opinion, but there's nothing that can be done about it. Spamcop and Sendmail acknowledged the fix almost immediately, but not Senderbase: for 4 days now, all clients on the server are having their emails bounce because of the reputation score.

Naturally, I'm losing hosting clients hand over fist because of it, and who could blame them? But it's completely out of my hands.

 

[cPanelTristan]

Enable the MailHeaders using easyapache and check the mail header, to find out is there any script is using for relaying.

If you are using PHP 5.3, then the PHP MailHeaders option is not available after PHP 5.3.4 due to the creator being delayed in releasing patches (CHOON.NET : Resources : Scripts & Patches : PHP Mail Header Patch latest is 11 Dec 2010 GMT +8, Updated to support version 5.2.15; Updated to support version 5.3.4). This means that EasyApache will not show MailHeaders for PHP 5.3.6 and 5.3.8 (the latest versions available with EasyApache).

The option for gathering details for PHP scripts would be to use this function instead:

PHP: Runtime Configuration - Manual

You could put the following into the global php.ini at /usr/local/lib/php.ini location:

mail.add_x_header = On

You might also want to log all PHP mail() function calls with this line:

mail.log = /path

Here replace /path with the log file you create such as /var/log/phpmail file.

 

[Infopro]

Regardless, an account that usually sends 30-40 emails a day is now sending 800, so I'm sure that there's a virus on their end, somewhere.

You were sure but did not change the password.

Once I found it, changing the password until the client fixed it on their end did work.

I think changing the password at the first sign of 800 emails would have been a better time to do that than to wait till you found something.

Unfortunately for me, Senderbase.org now gives my server a "Poor" reputation, which is rather undeserved in my opinion, but there's nothing that can be done about it. Spamcop and Sendmail acknowledged the fix almost immediately, but not Senderbase: for 4 days now, all clients on the server are having their emails bounce because of the reputation score.

Naturally, I'm losing hosting clients hand over fist because of it, and who could blame them? But it's completely out of my hands.

But it wasn't out of your hands, you knew of the 800 emails.

I don't want to sound harsh here, but your post deserves to be responded to. "Completely out of your hands" is not correct. As an Server Administrator, the moment you see something out of the ordinary you should try and stop it in its tracks. Then go look into it.

You don't mention how long this account was firing off emails but a phone call to the user to ask them to close their email client, unplug the computer, change the password on them even, should have been the first step.

800 emails is no where near enough to get any IP in trouble I don't think, so we should assume 1000's more went out including the 800 mentioned. Enough email went out that got you in trouble, we know that for sure.


I'm responding here not to pick on you, but to say that this happened to me as well a few years ago, and we must learn from our mistakes.

The moment I see that kind of email go out, I don't wait to ask the user anything, I shut the whole account down with suspension, or at the very least, change the email password. You only have to go thru this one time and hate it enough to get tough, quicker.

The "Poor" reputation is deserved whether you agree or not. Taking faster action next time is the only way around it.

My apologies in advance is this sounds like anything other than sound advice from someone who has been in this situation with you.

 

[ruzbehraja]

You were sure but did not change the password.

I'm responding here not to pick on you, but to say that this happened to me as well a few years ago, and we must learn from our mistakes.

The moment I see that kind of email go out, I don't wait to ask the user anything, I shut the whole account down with suspension, or at the very least, change the email password. You only have to go thru this one time and hate it enough to get tough, quicker.

The "Poor" reputation is deserved whether you agree or not. Taking faster action next time is the only way around it.

My apologies in advance is this sounds like anything other than sound advice from someone who has been in this situation with you.

I think this has happened to all of us at some point of time in some way.

Have you setup an hourly limit on the domains? Looks like it is still at the cpanel default (Unlimited)

Thats the first thing you should be enforcing.

WHM >> Tweak Settings >> Mail >> Max hourly emails.

This should be setup by default for all new accounts and you may want to put in something like 1000 to 2000 which is more realistic.
This would have definitely saved you from getting blacklisted or atleast delayed the process till you found a solution.

Time alone will improve your ranking....
If you have a couple of spare IP's you may want to switch some of your valuable clients to a dedicated IP temporarily, so that their mails atleast get delivered. Although I don't know whether the headache of switching the IPs is worth it.