mail(), shared hosting, be marked as spam?

blackhorse

On a shared hosting, when you use the mail() to send out the email, we will program to set up the sender, reply and return path etc. Some strict filter will mark it as spam, due to the sender was set up as different domain than the hosting server IP registered as.

But when we use the authorizenet etc to process the transaction, and authorizenet will send an email receipt to the shopper and set the the email as it is from the merchant (us) even the email was sent from authoizenet server. So authorizenet did the same thing as I did when I use php mail() function on a shared hosting server.

But their email get less chance to be marked as spam. Is it because the authoriznet's mail severs are "white listed" by most ISP spam filters?

Thanks!

MarkR

The problems are like that:

Your MTA is adding headers which look spammy, or has a configuration problem which causes messages to be refused or marked as spam. Common configuration issues are
the MTA uses an IP address for relaying which has a nonexistent or bad reverse DNS entry
The envelope sender domain being provided doesn't exist.
The message looks forged:
The envelope sender domain has SPF enabled which doesn't include the relaying IP
The "From" header is clearly forged (e.g. says hotmail.com and doesn't come from hotmail)
Seeing as you are on shared hosting, you are sharing it with a spammer. This is extremely likely, as shared hosting is usually used to host
Spammers directly
Crappy vulnerable PHP applications which have been compromised by spammers and used to send spam.
Your application is genuinely being used to send spam (or has been compromised to do so).

The chances are, if you're on shared hosting, you're sharing it with a spammer. Get off. Now.

Your shared hosting provider won't care about, monitor, or make any attempt to get off any blacklists that their mail relay's IP address has got on to (having said that, getting off blacklists is nigh on impossible anyway).

None of these problems are solvable while on shared hosting- you won't have any control over the MTA's configuration, reverse DNS or envelope sender (probably) and won't be able to get the shared provider to stop hosting spammers.

Mark

blackhorse

That one was solved. You are right. We rent the server and host only dozen sites we developed. All the forms on the server were protected from email injection attack, and I set up a script to monitor the mail queue to report the spam attack to us.

But it was a "guestbook attack". Someone kept on sending this client 50-200 spam a day through a form of his site for a few months. Server's mail queue monitor we set up cannot detect the attack by this small traffic. And that form also CCed to a 3 rd party hosting address. But that form was only a "contact us" form not a real online guestbook. So the client didn't realize it was a guestbook bot attack. But 3rd party hosting marked this domain and this IP as the spam, it might be their inside standard, greylist of their own. I checked the blacklists, that domain and ip was not on any public blacklists (thanks god). After we fixed the form add captcha to it, the bot spam stops, a week later, that 3rd party hosting unblock this client's domain.

But I have a new problems now. On my first server, I used the sendmail. So we can write the sendmail.cf and trusted-users to add the apache user as the trusted sender.

But on my second server (the hosting company set up for me) I just rent, the sendmail_enable was set to NONE in rc.conf, we are using the qmail. But the php.ini still sendmail_path still points to the /usr/sbin/sendmail. I tried to changethe sendmail_path point to the qmail, then the php mail() is not working.

So it seems to me that this new server is still using the sendmail for php mail().

My understanding is that you cannot both run sendmail and qmail, but could you run qmail for mail service, but only run sendmail for the localhost submit like mail()? If that is the case, after I change the sendmail's sendmail.cf and trusted-users set up and add the apache user as the trusted users. How can I make the sendmail recognize the new configuration of the sendmail, if I cannot restart the sendmail. If I restart the sendmail, it will confict with the qmail I am running, right?