All Mail Bouncing

[whking]

Actually my web (reseller) and all client accounts (nearly 100) use the Server IP. No dedicated IP.

So as the provider, you will know the blacklist incident to your server IPs, before we send the Tickets. Isn't it?

Anyway now most of email sending ok but it takes aroun 3 days to solve this.

Also the IP is on 5 Blacklists (Previousely it is on 7 BL) according to www.dnsstuff.com. Is it possible you te remove the ip from those BLs?
(Because anytime it will cause the problem)

For the support ticket : Yes, First I send the support ticket and it takes long time to get a reply

[Lena S.]

If you have already submitted a ticket on this issue please give us a ticket ID and we will try to speed up the process.
If your IP is backlisted, the best thing to do is also to contact our technicians and they will take measures to remove it from blacklist.

[whking]

Yes that's right.
But this is not only belongs to me and i think there are many resellers on this account.
And at the moment the problem has solved. But the SERVER IP is on 5 Blacklists at the moment. I think it is too high (or abnormal) Isn't it?
(Anyway i am not an expert to tell exactly, but my other reseller accounts don't have such a result)

So it is very good if you can remove the server ip from those blacklists too. I think all resellers on this server agree with me.

[Alan B]

Sometimes you may know about the blacklisting before Support does. That's why I suggested that the first step is to report this to Support. They will investigate to find the source of the problem on the server, then they will contact the blacklists to request removal. Support does not have the power to directly remove the IP from the blacklist. Support must request removal from each list, after first suspending the problem account.

No, it is not abnormal. It is undesireable, but not abnormal on shared hosting. Unfortunately, blacklisting happens periodically for shared servers. Likely someone on your server was sending spam, or had a high-volume mailer sending uncontrolled amounts of mail in a short time. Because all senders on a shared server share the same mail server IP, when that spammer gets blacklisted so does everyone else on the server.

That's why I suggested that you tell your clients to set their ISP's SMTP server for outgoing mail, thus bypassing any blacklist issues with the WHB server. IMHO, it's better to have your clients always use their ISP's SMTP server for outgoing mail.

[bmcc81]

To fix my outgoing email settings I had to go to my internet service provider and check what the SMTP outgoing settings where.

I find it strange, because before I never had to do this. Must be a new thing.

However for outgoing mail server for Videotron (Mtl service provider) it was:
relais.videotron.ca

I attached photos if anyone would like to see the important things that I changed.

- bmcc81

[JamesFu]

In the meantime, I suggest that you tell your clients to set their ISP's SMTP server for outgoing mail, thus bypassing any blacklist issues with the WHB server. IMHO, it's better to have your clients always use their ISP's SMTP server for outgoing mail.

Hi Alan,

I'm new to this forum despite having had an account here for 1.5 years now. I see you're very helpful here and hope you can shed some light on this problem I'm facing that WHB Support wasn't able to resolve.

I have some forms on my sites that need to send emails. These sites all have "A" records pointing to WHB but "MX" records pointing to Google Apps. I ran into a series of problems along the way:

1. "From" email not of a domain hosted here.
2. Changed "From" email to one of a domain hosted here, but delivery fails when "To" email IS one of a domain hosted here.
3. Support advised me to set up a mail.domain.com subdomain and email accounts (*@mail.domain.com) matching those used in my "From" field. This was not an option for me due to the sheer number of domains I host and subdomains and mail accounts I'll need to set up, not to mention the unreliability of "Reply-To" header to ensure recipient replies to the correct address, setting up email forwarding in *@mail.domain.com to *@domain.com, blah, blah...
4. Next I tried to send the mails by authenticated SMTP socket connections using php PEAR through Gmail's servers, but got a connection timeout error which Support confirms was due to blocking of socket connections for "security reasons".

I was just wondering if what you said about using "ISP's SMTP server" referred to php scripts or the users' email clients? And if it's the former, how did you circumvent the "security" policy?

Here's a link to my codes and thank you so much for your time.

Best regards,
James Fu

[Alan B]

Your ISP's SMTP server has absolutely nothing to do with outgoing mail sent from forms on your WHB-hosted web site.

WHB mail security policies won't allow you in a a form mailer to specify a FROM address that is not hosted here. That's why you saw those failures.

If you send TO a domain that is hosted here, Exim (server mail transport) will deliver the mail locally without leaving the server. Since you have those domains' Mx hosted at Google, you should request Support to remove those domains from the localdomains list. That will allow the messages to be sent off the server and handled by Google. If you have a Reseller account, you can change settings yourself to accomplish this.

[JamesFu]

Hey Alan,

Thanks for your reply. My ISP's SMTP server will have a lot to do with outgoing mail from forms if I sent it out using my ISP's email account credentials in an authenticated SMTP socket connection, no?

That said, I think you managed to answer my question, so thanks a lot!

So for posterity, if anyone has trouble sending out mail "To" a domain whose "A" record resolves here, but "MX" record points elsewhere, just delete the "MX" entries here!

Best,
James

[Alan B]

Thanks for your reply. My ISP's SMTP server will have a lot to do with outgoing mail from forms if I sent it out using my ISP's email account credentials in an authenticated SMTP socket connection, no?

No. The form is on your WHB server. The form initiates a request to send outgoing mail from your WHB server. Your ISP has nothing to do with it.

So for posterity, if anyone has trouble sending out mail "To" a domain whose "A" record resolves here, but "MX" record points elsewhere, just delete the "MX" entries here!

No. Don't mis-state what I wrote. If the DNS Zone is hosted here, you still need Mx entries, otherwise mail will fail.