Results 1 to 10 of 10
  1. #1

    Help! My host's (hostrocket) spam filter is blocking legit mail to me

    Hi, I have a shared hosting account (for a personal website/blog and for the associated email accounts) with hostrocket and have been pleased with them for the almost 4 years I've been with them. Until recently (about a month ago, actually). I'm having two email problems, and despite getting decent turnaround on their responses to my problem, they have ultimately told me that the problems do not lie with them and they won't do anything to alleviate things. So, I'm looking for advice as to alternatives, either changing hosting companies, or finding some other way to deal with the problem. Let me explain the problems:

    1) I have several family members who use Charter (US cable company) as their ISP, and in the last month, their mail to me has been rejected by the hostrocket mail servers because the charter mail servers are listed on RBLs, in every case but one on the same RBL, namely PSBL ( The sender gets a bounce message back about 24 hours later stating that the message was rejected because of PSBL, and there's a link to PSBL with the IP address of the offending server. It's easy enough to take the Charter server off the blacklist, but the problem is that there are tons of Charter servers, and the mail gets directed through a different one each time, it seems. And all of these servers seem to have problems with PSBL. Taking them off manually doesn't get the job done. I've notified Charter of the problem, but they quite frankly seem to be incompetent or uninterested. Plus, of the dozens of servers Charter seems to be using and which end up on the PSBL, only one of them has shown up on any of the other blacklists I was able to check. Charter seems to have a problem almost exclusively with the PSBL. But this means that my friends and family on charter can't get email to my primary email address at hostrocket.

    2) I have an alumni forwarding service address from my university (evidently very common, where you can get a permanent email address, johndoe(at) that simply forwards to the email address that you tell your college to use). These emails are being blocked by hostrocket's filter now too, no matter who the original sender, because of SPF checking. The bounce message links to a page that reveals that SPF is checking the SPF record of the originator's SMTP against the IP of the forwarding service, and thus it fails. Forwarding accounts are a known issue for SPF, as you can read on pp.15-16 of the SPF whitepaper ( [Sorry, the forum won't let me give actual links in a post because I'm a newbie.] Hostrocket seems to think that this is the forwarder's problem, but finding out whom my college has outsourced to for this appears to be no easier than getting Charter to deal with the other problem.

    Hostrocket has a newly implemented spam filtering solution (they haven't officially announced it to the public or their users, but it's there in the email control settings), and it is possible to set whitelists. I've placed all the email addresses (and indeed the entire domain) on my whitelist, but that doesn't work, because I've been informed by their techs that the whitelist is not checked until after the mail has been accepted by the hostrocket server (and thus checked against both RBLs and SPF).

    For both problems, I've tested things with other destination emails that I own (yahoo, gmail, my work address, etc.), and there are no problems except with the hostrocket account. Hostrocket wrote me telling me that they cannot turn off filtering for the account (which for me is not ideal either) and that their whitelists do not work before server-side email accepting or rejecting has been accomplished. Thus, I'm stuck. I either use my other email accounts or I find another provider. Unless there's another solution. I was hoping that hostrocket was honing their new spam filtering service, but I suspect that they are going to be stubborn. I hate spam, and I know their reasons for implementing their system are because of the recent huge swell in spam (particularly gif-based financial spam), but their solution is making me run into the arms of another provider. Hostrocket hosts the domain with my primary email address used by almost all my acquaintances, so something has to give.

    I've read in the forums here that some people had similar problems with godaddy's mail filters, but I'm wondering if there are other host providers that have implemented better spam filtering systems. Or am I being unreasonable to expect better than what hostrocket has claimed they're doing? Any experiences/suggestions of where I should go from here?

  2. #2
    Join Date
    Jan 2003
    Lake Arrowhead, CA
    I don't think you are being unreasonable to expect your ISP actually let you receive your mail

    RBL checks can be done both before the server sees the mail (the point being to block bad hosts before they cause server load) or as part of a spam rating (eg: spamassassin) system which allows both email and IP address overrides to allow exclusions.

    The bottom line is if an RBL isn't accurate, then they need to stop using it on the front end and only use it as part of the rating system. There are plenty of more accurate (single IP) RBLs and most can be downloaded and modified by the host to allow exclusions for known addresses. If HostRocket insists on using marginal RBLs (like PSBL) in front of their mail servers, then you will have no choice but move your mail elsewhere.

    That said, in most cases I would hope that simply reporting bad blacklist entries often enough should be enough for the host to stop using that list.
    Stability, redundancy and peace of mind

  3. #3
    Join Date
    Feb 2006
    Los Angeles

  4. #4
    Thanks, SROHost, for the explanation of the RBL issue and whitelist possibilities. Hostrocket does use SpamAssassin, but as you said, these emails are bouncing before the spam rating gets done. It sounds like hostrocket's implementation is poorly conceived. Any thoughts on the SPF and forwarding issue?

    And MarkFrompf, thanks for the suggestion there as well. I'd consider GoDaddy except for two things: 1) I don't think they offer imap, and 2) their owner is a military hawk goober. Any other suggestions, though?

  5. #5
    Join Date
    Jan 2003
    Lake Arrowhead, CA
    Quote Originally Posted by copecetic
    Any thoughts on the SPF and forwarding issue?
    The SPF issue can be resolved in one of four ways, none of which are particularly attractive or easy :

    1) Have the original domain's SPF record updated to allow the forwarder's IP as a designated sender.

    2) Have the forwarder re-write the from address to their own domain. Commercial forwarders should be able to do this, but you'd have to FIND THEM first .

    3) Use a host who does not do any SPF checking.

    4) Don't forward .

    Of course, forwarding can also present a spam issue in itself. If one host forwards mail prior to its own RBL/spam checks and the receiving host trusts the forwarding host, then spam coming to that address may never be filtered at all. I personally check a half dozen independent email accounts separately for that exact reason.

    There really isn't any "easy" solution to this. Even the best hosts have trouble with these issues. The big question is, will they work with you on it?
    Stability, redundancy and peace of mind

  6. #6
    Any host using an SBL that is blocking large legitimate mail servers should be switched from immediately, IMHO....

  7. #7
    Quote Originally Posted by SROHost
    3) Use a host who does not do any SPF checking.

    4) Don't forward .
    I wish I had an option on the forwarding, but I don't. My university used to give alumni accounts an actual webmail box, but now it's forward-only on those addresses.

    As for #3, is it possible for the system to be set up so that SPF checking exists, but that a whitelist record overrides it? Is that what the 'softfail' setting is in SPF checking? If so, it appears that sometimes forwarded emails 'softfail' at hostrocket and do get through after all. But sometimes, the same path (originator and forward) produce bounced email, i.e. a hard 'fail'.

    When it fails, the originator gets a bounce message with a link to an SPF explanation website, which gives this info:
    "0 ( rejected a message claiming to be from [email protected]. 0 ( saw a message coming from the IP address which is; the sender claimed to be [email protected]. has announced using SPF that it does not send mail out through However, the domain is still in transition. The message should not have been rejected."

    The ip address is that of the forwarding service, I'm pretty sure. The way I read this: the SPF checks the forwarding server's IP against the SPF record of, and of course it fails. But what does this "However, the domain is in transition. The message should not have been rejected" mean? Is SPF checking set up incorrectly at hostrocket?

    The webpage goes on to explain:

    "If you are [email protected]:...
    If your mail was correctly sent, but was rejected because it passed through a forwarding service, you can either mail the final destination address directly (it should be shown in the bounce message) or you ask the forwarder to implement SRS. If neither of these suggestions is practical, change your "-all" to "?all" until a more comprehensive approach to sender authentication involving cryptography solves the forwarding problem for good. For more information on this problem, see pages 15-16 of the SPF Whitepaper."

    Are they suggesting that charter set their SPF record to "-all"? Is the problem with charter after all, i.e. there's no setting that hostrocket could implement that would make this work?

    As for successful examples, let me give two partial headers. The first comes from a family member's account at charter, through the university forwarding, and onto the hostrocket account (most of the time, these bounce back to the originator, i.e. they 'fail' the SPF test, but sometimes they go through, giving this):

    Received: (qmail 95827 invoked by uid 89); 5 Nov 2006 20:12:00 -0000
    Received: from (
    by with SMTP; 5 Nov 2006 20:12:00 -0000
    Received: (qmail 2145 invoked by uid 89); 5 Nov 2006 20:07:08 -0000
    Received: by simscan 1.2.0 ppid: 988, pid: 1179, t: 4.3012s
    scanners: clamav: 0.88.4/m:40/d:2087 spam: 3.1.0
    X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on
    X-Spam-Level: X-Spam-Status: No, score=-100.0 required=8.0 tests=USER_IN_WHITELIST
    autolearn=ham version=3.1.7
    Received: from (HELO (
    by 0 with SMTP; 5 Nov 2006 20:07:04 -0000
    Received-SPF: softfail (0: transitioning SPF record at does not designate as permitted sender)
    Received: from ( by (7.2.073)
    id 45352B5C001BE556 for xxx@[hostrocket domain]; Sun, 5 Nov 2006 20:11:54 +0000
    List-ID: <[email protected]>
    Precedence: bulk
    Received: from ( by (7.2.078)
    id 454B8577003CD9E1 for xxx@[]; Sun, 5 Nov 2006 20:11:54 +0000
    Received: from ( [])
    by ( with ESMTP id kA5KBqaC005381
    for <[email protected]>; Sun, 5 Nov 2006 15:11:52 -0500
    Received: from (HELO xxxxx) ([])
    by with ESMTP; 05 Nov 2006 15:11:43 -0500

    Let me see if I'm reading this correctly: from charter domain, the email travels to the alumni forwarding service (which are the domains. When it gets to an SPF check (I assume at the exterior of hostrocket's system), it gives this 'softfail' result but still goes through to then get checked by Spam Assassin, where the email is passed on regardless of content because the orginator is in my whitelist. I guess the question is: why does the SPF check produce a softfail in this instance when in other instances (email from the same originator at charter), the SPF check must produce a hard 'fail', which bounces the message back to charter instead of letting it go through?

    Example 2: this header from email sent from gmail to hostrocket via the alumni forwarding.

    Pretty much the same except the SPF header line:
    Received-SPF: neutral (0: is neither permitted nor denied by SPF record at

    Does this just mean that Google has set up SPF records that are incredibly permissive and therefore could not fail hostrocket's SPF test?
    Sorry to get so technical, but I'm curious as to the explanation of discrepencies 1) between different results of SPF checks from different instances of mail originating at charter; and 2) between successful pass-throughs of email originating at charter and those originating from gmail.

    I'd guess I'd like to know if there's defintive information to be learned here that I then could take to the techs at hostrocket. This SPF crap sure is confusing!!! If anybody can get through all my questions, they're incredibly saintly!

  8. #8
    OK, I have some great news! After more consideration on the part of hostrocket (I'd like to think partly because of my complaints and because of the help I had here, which I passed on to them--but in all likelihood because they're pretty smart techs, in the end), they are going to change the way they treat RBL-failed mail:

    I am happy to announce that we are going to be using Spam
    Assassin in conjunction with the real time blacklists we use
    to allow our customers filtering preferences to affect
    blacklisted emails. Within the next few days we will stop
    rejecting mail outright when it is blacklisted and instead
    mark it up as SPAM and let your filters decide if you want
    it delivered or not.
    For the time being, I'm cautiously optimistic that hostrocket is going to get it right on the blacklisting. I'll let you know how it comes out.

    Let me say this: in general, I've been remarkably happy with hostrocket, which is why I've gone through all this trouble to work things through with them. If they get all this straightened out with their email (and I think they probably will, at this point), I can recommend them generally, although I'm by no means a power-user. I run a minimal website with them, with a blog, data backup, and picture hosting, but I use their email services extensively. This situation was the first time I've ever come close to giving them the boot. They are generally quite responsive and for my needs, an effective host provider.

    My troubleshooting of the SPF and alumni forwarding problem is not resolved entirely, though. Here's what they now say to that:

    As far as SPF records go, while they are not perfect by any
    means, there are several things to consider.

    The first being that the owner of a particular domain name
    decides if they wish to implement SPF records. All our
    servers do is check to see if they have decided to use them
    and respect their wishes. If the SPF records are causing a
    problem, that domain can choose not to use them. If the
    Universities decision to implement SPF records is causing
    problems with their alumni email services, they may be
    willing to remove the SPF records.

    Another issue to consider is the amount of phishing scams
    (or just plain spam) that SPF records prevent. Without SPF
    records anyone anywhere can send an email that appears to
    come from any domain they choose. For example, they could
    send out an email pretending to be Paypal or Ebay that looks
    like it actually come from one of those companies. With an
    SPF record, those mails never reach their destination
    because they are not authorized by the domains owner to send
    mail from that location.

    Thank you for your patience and thank you for choosing
    Ok, that seems fair enough, although I'd still like an explanation of what exactly is going on with these forwarded emails, if anybody wants to look at the headers I posted yesterday. I have now contacted the support group at my university to let them know of the problem with their forwarding service, and they are looking into it. I'll let you know what they report on that. Thanks for all the help so far; you folks have definitely made me feel better about the world!

  9. #9
    Join Date
    Jan 2003
    Lake Arrowhead, CA
    Glad to see HostRocket is working with you on this as that is always the best option.

    As for the SPF issues, HostRocket's description was spot on. Both the domain SPF record and receiving server's SPF fail settings affect the outcome. In any case, if the FROM line of the mail shows a domain without an SPF record or one with an SPF record matching the sending (or forwarding) server, it should never fail. That's why forwarders should rewrite the from line to match their own domain.
    Stability, redundancy and peace of mind

  10. #10
    Join Date
    Oct 2002
    New York

    HostRocket implemented a way for whitelists to circumvent the RBL checks, while RBL's do add spam points, you can either raise your threshold, or whitelist the RBL listed sending domain, atleast thats what they told me, and it seems to work quite nicely

    Im not sure about the SPF thing, but I do know that SPF is catching on very quickly with all todays spam/joejobbing garbage out there, so you might need to go directly to the source, the people who host your SPF txt record

    Good luck!
    The Hostworks:: Offering Managed and Unmanaged VPS
    Shared Web Hosting and Managed E-Mail security services.
    24/7 Support :: 10 year anniversary coming soon!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts