5

A site for my client has the run-of-the-mill "website with users" email pattern. Create an account, get an activation email. Get an email when a subscription is expiring, etc.

The site is hosted on Bluehost and currently it uses php's mail() function. There isn't much configuration that is allowed (as far as I know).

The trouble is, about a third of these emails disappear into the void. They aren't in spam or junk folders, there's no bounce message, they just cease to exist. I've read about Bluehost email troubles but I can't figure out what my options are for fixing it. These aren't marketing emails, ie they have user-specific information contained within them. I suppose if a solution offers a good templating system that would be fine.

What are my options?

Excerpt of headers when delivered to a Gmail address:

Received-SPF: neutral (google.com: 00.000.000.000 is neither permitted nor denied by best guess record for domain of domain@box###.bluehost.com) client-ip=00.000.000.000;
DomainKey-Status: good
Authentication-Results: mx.google.com; spf=neutral (google.com: 00.000.000.000 is neither permitted nor denied by best guess record for domain of domain@box###.bluehost.com) smtp.mail=domain@box###.bluehost.com; domainkeys=pass [email protected]

2 Answers 2

7

You are probably hitting a common problem with shared hosting: a fairly bad user (or a number of mildly bad users) or insecure script on your server that is sending (or allows other to send) out junk will result in all mail from that IP address getting suspected of being junk. Even if you have dedicated IP addresses for your websites and other services to respond to you will probably find your outgoing mail will appear to come from the same address as every other account on the server.

Likewise many problems in the host's range of addresses can get mail from anywhere in their range being considered suspect (though this affects all hosting arrangements, not just shared hosting).

It would be worth seeing if you can see the headers of the mails that are getting marked as spam and going into people's junk folders as some spam detectors will add notes to the mail headers to indicate which measures it used to make the judgement. This will save you trying to solve a problem that doesn't exist. Most anti-spam setups will just throw away mail that really really looks like junk by its measures. That is probably what is happening to those mails that are "vanishing into the void" - it is unlikely that they are getting lost at your end. For example, the headers added to an obvious junk mail to me when SpamAssassin picked it up were:

X-Spam-Flag: YES
X-Spam-Score: 9.959
X-Spam-Level: *********
X-Spam-Status: Yes, score=9.959 tagged_above=-10 required=5.4
        tests=[BAYES_99=3.5, DYN_RDNS_SHORT_HELO_HTML=0.499,
        HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1,
        URIBL_BLACK=1.955, URIBL_SBL=1.499, URIBL_WS_SURBL=1.5]

You can help the situation by setting up the relevant DNS entries for DomainKeys, Sender ID, Sender Policy Framework, ..., ..., ... for your domains, but if the host's IP addresses are in blacklists this can be of relatively limited utility.

If the hosts's IP addresses are on black lists you could ask the host to follow what-ever procedures are present to try rectify that. If they do not do this, switching hosts may be the best option.

You could also setup your own outgoing mail relay on a cheap VPS (even the "silly small" 1-or-2-$/month VPSs would run a simple mail relay for you) to separate your mail from that of other accounts on the server(s) you app runs on, but while you are probably the only person sending from the address you are assigned in that case you could still run into the problem of that host having all its range blacklisted because of other users.

To cut a long story short: there may not be an awful lot you can do in the end. Mail never was a truly reliable transport and it is getting increasingly less so due to the spam/anti-spam arms race, so you will never be able to guarantee all your mail gets through.

11
  • I've looked at the header (see above). Any tips? I'm afraid this is something I have never dealt with before.
    – colithium
    Dec 20, 2010 at 23:00
  • 1
    I just outsource this kind of thing to authsmtp.com. Few bucks a month, and it just works. They specialise in sending mail, and do it well. Let them do it for you. Dec 20, 2010 at 23:47
  • 1
    @Tom: outsourcing can be a good solution, but if he is using a $6.95 shared hosting account he isn't going to want to pay $24+ on top for the mail outsourcing! Dec 21, 2010 at 9:14
  • 1
    @David depends how much you care about your mail. Also, $24 a year isn't that much... Dec 21, 2010 at 9:42
  • 1
    @207381 - it can certainly help a fair amount if they can keep their proxy IP off the block lists which when it is a shared address/range (as it will be). It at least pushes the ball further into their court in terms of who deals with the problem when it occurs. Apr 10, 2020 at 1:19
0

It's because bluehost relays email through their parent company email servers. They have something called Bluerock which uses different servers, see here https://www.bluehost.com/help/article/dns-spf where they say "These accounts do not use unifiedlayer.com proxy IPs as the outgoing email server" right under the Bluerock heading.

I have the same problem with a bluehost shared hosting domain and with SPF/DMARC/DKIM all set so they show in checkers as good it turns out that bluehost then relays through eig servers (includes unifiedlayer servers) since that is who owns bluehost since 2010 https://www.onlinetoolsexpert.com/full-list-of-eig-web-hosting-companies/ , and the relaying causes the rejection as the relay isn't in SPF and there's no good way to add eig in SPF as they have so many servers and of course are often blacklisted.

Here's a snippet from viewing mail source on a rejected message:

Return-Path: [email protected] Received: from cmgw12.mail.unifiedlayer.com (unknown [10.0.90.127]) by progateway6.mail.pro1.eigbox.com (Postfix) with ESMTP id F1C4010047D6E for [email protected]; Sun, 2 Apr 2023 19:34:33 +0000 (UTC) Received: from box2304.bluehost.com ([50.87.182.158]) by cmsmtp with ESMTP id j3TFpE0Wzuftbj3TFpKU4u; Sun, 02 Apr 2023 19:34:33 +0000

2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .