Invoices and notice emails marked spam on gmail

[eger]

Wondering if anyone else has a problem with emails from WHMCS being sent to the Gmail spam folder?

 

I have SPF, Reverse DNS setup, and from the headers a customer sent me it looks like everything is correct coming from my server. I am not sure why the invoices and notices are being marked as spam (also happens on Yahoo Mail sometimes).

 

Wondering if anyone has had any related spam issues with WHMCS sent emails.

[generic]

customers settings, and or you need to check your domain/ip with the major spam blockers to see if your blacklisted.

[reds]

Gmail marks form emails as spam.

[Rae]

A couple suggestions:

 

Try using the SMPT settings instead of phpmail(), which is sometimes identified as spam from the free email providers.

 

Also have your customers add your email address to their address books.

 

--Rae

[brianoz]

My bet would be it's picking up on the use of the php mail() function. Try out using SMTP to send email and let us know how you go - it would be useful information for everyone.

 

I have seen bad From fields causing emails to be treated as spam.

[Joweb]

All my mail being marked spam when sent through whmcs. I am using SMTP for sending mail. Even the WHMCS support request link inside WHMCS returns my mail but if I send it from inside my server they get the mail. Yahoo and frontier mark it spam and hotmail discards members don't get mail at all. Any ideas anyone? Anyone having the same problem here?

[frisco]

I was having this problem with any email being sent from php forms.

 

I discovered, after a LOT of trial and error and searching, that the headers in the outgoing email were showing the sender as "nobody@server.domain.com", and that changing this to a real email address seemed to be the magic bullet.

 

The confusing part of fixing it was a comment in the default php.ini file that said a particular setting only applied to Microsoft servers, and I am using Linux -- but the Linux servers do, in fact, use this setting, despite the comments in the php.ini file.

 

Here is how to check and change it:

 

First, do php -i |grep php.ini to find the location of php.ini file

 

Second, edit the file in your favorite editor, and search for "sendmail_from"

 

Third, change:

 

;sendmail_from = [email]me@localhost.com[/email]             ;
sendmail_path = /usr/sbin/sendmail -t -i              ;

to

sendmail_from = [email]postmaster@yourdomain.com[/email]             ;
sendmail_path = /usr/sbin/sendmail -t -i -f [email]postmaster@yourdomain.com[/email] 

 

(The "postmaster@..." should be on the same line as the "sendmail_path and after the "-f" and a space -- the forum software is breaking the line there on my preview)

 

Finally, restart Apache "service httpd restart"

 

 

 

It worked for me -- especially with bounces from AOL.

 

Hope it helps...

 

Bill

[trine]

there are a few other ways to accomplish this, including adding the following entry to the virtual host in the httpd conf: php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f existing_default_user@the_domain.com

 

To add that with all new accounts, you'd have to modify the postwwwacct script.

 

And yet, another, better, no... most likely best way to do this is to modify the phpsendmail script:

 

#!/usr/bin/perl

$/ = null;

$input = <STDIN>;

open (MAIL, "|/usr/sbin/sendmail -t -i");

print MAIL qq~X-PHP-SENDER: $ARGV[0]

$input~;

close(MAIL);

 

and then modify phpopenbasectl (around line 71):

 

print HC "<IfModule mod_php4.c>\nphp_admin_value open_basedir \"${homedir}/:/usr/lib/php:/usr/local/lib/php:/tmp\"\nphp_admin_value sendmail_path \"/usr/sbin/phpsendmail $owner\"\n</IfModule>\n";

 

---

There are some advantages to each, but take it for what it's worth. The first above does create a few potential security issues... last is best.

[brianoz]

headers in the outgoing email were showing the sender as "nobody@server.domain.com", and that changing this to a real email address seemed to be the magic bullet.

Actually there's something else important that should concern you here.

 

The fact that your emails come from nobody@ means that you are running your PHP as a shared module, running under the user id of nobody. That means that any user on the server can harvest your WHMCS database looking for credit cards, usernames and passwords.

 

The only way to stop that is to use a dedicated server (or, almost dedicated, with only a few trusted and secure users on it); or to use the suexec/phpsuexec patch to PHP to make it run as a separate user for each different account. While this may be a barely acceptable risk for a small company (<200 accounts) I wouldn't want to leave this risk alive if I was serious about building my hosting business.

 

(By the way, WHMCS does everything "right" here, making it much harder to exploit the information as far as I know. The problem is with the server architecture not WHMCS.)

 

The problem you're getting with emails from WHMCS being marked as spam is really a combination of the fact you're running your PHP as the nobody user (shared across all users on the server, just to emphasize a point!) *and* you're using the PHP mail() function with the default settings. As mentioned earlier one fix is to use SMTP, but the superior fix is to fix your PHP.

[Joweb]

As I stated earlier I am using the SMTP function not PHP mail() and this is still happening.

[Dominic]

Check the spam report in the message headers.....

 

One thing I've found that spam filters don't like is the hyperlinked image fpr the email header. Even when taking out the URL in the admin config, whcms still seems to place it there - just with a 'no image' URL.

 

Not sure if that's totally correct as I haven't looked into it fully enough to query it, but that and the PHP mail() seem to be the main causes. Anything else would be down to the wording of people's individual e-mails

[Joweb]

I have doubled checked my config in whmcs and I have smtp setup could it be not functioning and sending mail php mail() by default how could I check this?

 

The bounced mail from WHMCS support states from nobody@myservername.com should it not state from the email I am using like support@mydomain.com A little confused here.

[brianoz]

If it's from nobody@ you're pretty much definitely sending the email via the PHP mail() function, not SMTP. Not sure what your settings are but something must be wrong somewhere.

[trine]

Joweb, as brianoz points out, it is probably sending using the default phpmail(). You should double check that your SMTP settings are 100% correct. By sending with SMTP, you would normally not have Return-path set to nobody, but the SMTP user.

 

As a test, and if you are root on a cpanel/whm box, you can go into whm and tweak settings, and check prevent nobody from sending mail. Send a message again, and chances are it won't send anything... That would confirm that your SMTP connection is not working and your WHMCS is using the default php mail() instead.

 

--

 

Dominic, linked images in the body of an email can increase your spam score. Best policy is to have an html and text in a multi-minemessage, or even better, simply text only.

 

--

 

brianoz, just because you run PHP as nobody and do not use phpsuexec, does not open up a security hole by and in of itself. (don't scare people like that)

 

Anyway, your point is well taken that as a precaution, it is best to run it elsewhere in a secured environment rather than on the same host as the accounts.

[Joweb]

Trine

Thanks, I have disable the prevent mail from nobody and tested WHMCS. It is now using SMTP configs. My setting where correct maybe my server was making it from nobody as a default? Not sure, now my question is should I leave it set to prevent mail from nobody. What will that change if anything.

 

 

Here is the return header after I disabled send mail from nobody does this mean WHMCS is still sending mail from nobody?

 

Department: Postmaster

Subject: Mail delivery failed: returning message to sender

Priority: Medium

 

This message was created automatically by mail delivery software.

 

A message that you sent could not be delivered to one or more of its

recipients. This is a permanent error. The following address(es) failed:

 

support@whmcs.com

unrouteable mail domain "whmcs.com"

 

------ This is a copy of the message, including all the headers. ------

 

Return-path:

Received: from nobody by server.myserver.com with local (Exim 4.63)

(envelope-from )

id 1HVU1n-0006qi-AX

for support@whmcs.com; Sun, 25 Mar 2007 10:48:40 -0400

To: support@whmcs.com

Subject: Made changes to my server

X-PHP-Script: mydomainname.com/billsys/admin/systemsupportrequest.php for 70.101.181.114

MIME-Version: 1.0

Content-type: text/html; charset=iso-8859-1

From: My company, LLC

Message-Id:

Date: Sun, 25 Mar 2007 10:48:40 -0400

[trine]

Joweb,

 

That is your call. If you have numerous client accounts on your server, and wish to use that setting, you should email your clients to check that their php scripts are not sending using nobody.

 

With the php mail() function, you can add an option flag to it, so that it uses -f email@domain.com. That would force their email to be sent with the email they define.

 

But, you should also consider making a few small adjustments to your server to ensure that it does not cause any problems for your end-users.

 

If you look at frisco's example above, or my second example above (adding a phpsendmail script), that can also do the trick. Both of those will set the sender to a domain sender, rather than something like nobody@host. If you add it using a phpsendmail, make sure to chown it to 755. You will also need to add the <IfModule mod_php4.c> and <IfModule mod_php5.c> to the phpopenbasectl.

 

Try not to add the php_admin_value sendmail_path to the httpd config, even though I provided the example. If you are not alone on the server, it can raise some nice security issues, as I noted above.

[trine]

Trine

What will that change if anything.

Again thanks

 

Sorry I forgot to answer the obvious. ...

It will simply prevent scripts on the server from sending out as nobody, so any of the suggestions I made above should remedy that. It doesn't harm anything, but does allow for a bit better tracking, and in the event of someone using your server to send spam, will ultimately allow you to trace those better.

 

Also, rebuilding PHP with PHP SuExec support would also allow you to track down script spam users even better, but also raises additional concerns, since with phpsuexec, all scripts are run as the user and not 'nobody'. Some scripts have problems with suexec, although arguably, it provides some additional security.

[brianoz]

brianoz, just because you run PHP as nobody and do not use phpsuexec, does not open up a security hole by and in of itself. (don't scare people like that)

 

Anyway, your point is well taken that as a precaution, it is best to run it elsewhere in a secured environment rather than on the same host as the accounts.

I don't know how to say this, but I have to emphatically disagree. Running without phpsuexec on a shared server is a major exposure for your billing system (actually for any account). The vulnerability is that ALL database usernames and passwords can be read by any account on the server, or any exploited account on the server. I'm not making this up; it's true. [i've been a unix sysadmin/programmer/trainer/lecturer for 25 years] So, do be scared :wink:; turn on phpsuexec, and do it now, trust me; you need multiple layers of security and this should be one of them. By the way, phpsuexec/suexec is NOT a magic security immunity pill, you have to do stuff like mod_security and others as well!

 

Thanks for taking my other point though

[brianoz]

Also, rebuilding PHP with PHP SuExec support would also allow you to track down script spam users even better, but also raises additional concerns, since with phpsuexec, all scripts are run as the user and not 'nobody'. Some scripts have problems with suexec, although arguably, it provides some additional security.

I agree it's not entirely trivial and that some scripts will be affected - it's surprisingly few though (for instance, all 50+ Fantastico scripts work). The problems you'll run into are:

1. Use of php_admin and php_value in .htaccess files (fairly rare - move directives into php.ini files);
   
2. Permissions on PHP scripts - must be 644 or 755, can't be 777 (fixable with running a few scripts - /scripts/fixsuexeccgiscripts and /scripts/chownpublichtmls);
   
3. Very rare: PHP_AUTH_PW and PHP_AUTH_USER in scripts (not used often).

Despite these three listed items, any problems at all are rare providing you fix permissions and ownerships by running those two scripts.

 

The other problems can be located with grep -r and some CPU time, eg:

locate .htaccess | xargs grep php_  /dev/null
locate .php | xargs grep PHP_AUTH_ /dev/null

I've been pondering a howto on converting for a while now since there seems to be heaps of FUD around on this for some reason that I've never understood.

 

[bTW - another essential security toolbox item is the firewall CSF - a great tool which integrates fully with cpanel (works well on non-cpanel too) and is actively maintained by the author, unlike the older and now outdated APF and the somewhat unstable BFD). It can also self-update which is a boon.]

[trine]

Brian, I was saying "by and in of itself" ... The same goes for WHMCS requiring register globals set to on... It's not dangerous in and by itself either.

 

Of course it is crucial to secure your box, in more ways than was covered here. CSF is indeed a very nice solution and an especially excellent tool for "noobees", since it simplifies managing a statefull firewall, along with a few other very nice tools by the same author. I do agree, in shared environments that enabling php suexec is preferred.

[RoadStar]

I know this is an old thread but somehow the question is still current:

I'm setup using SMTP for mail and works as expected. Problem is the mail is sent to spam box and I susspect is becuase the image and link in the body of the email.

Can someone please tell me how to remove the image and link from the body part of the email.

Thank you

[Miron]

Hi,

 

Same issue here.

Every mail sent via WHMCS is marked as spam, regardless of whether I send html or plain text.

I have configured SPF, DomainKeys, dedicated server, phpsuexec.

What else I can do?

 

 

Thanks

[jrnetwork]

I'm getting this a lot too, many of my clients get my emails in their spam folders and they don't see them, so therefore they are not paying their invoices. It's becoming very frustrating.

[AJX]

We have the same problem. All security related configuration including SPF, DKIM, DMARC is OK and we got 10/10 on some email testing sites. But gmail spams our emails. Do you have any solutions?

[sol2010]

Just started getting this issue with Gmail.

Have correct PTR, DKIM, SPF and DMARC all set up and have checked blacklists - all clean - but Gmail says "lots of emails from domain.com are identified as spam".  We are not spamming anyone, only sending out invoices and support replies.

 

 

Edited October 2, 2023 by sol2010