Emails not going through to other Jodohost domains

I've got some clients complaining that emails sent from their domain hosted on Jodohost is not being received by people using other domains hosted on Jodohost.

For instance, my client's email is wpo@*****dr.com, which is hosted on wincf3. He sends a message to my account at gary@***********er.com (hosted on win6), and CCs it to my GMail account.

I might never receive it through the Jodohost server, then again I might get it 20 minutes later. It will always come through on GMail in seconds.

However, he has set up another domain on his account for his wife's business. If he sends her an email from his account, she NEVER receives it in her new account. He has to send emails to her Yahoo account. So the same shared account with 2 domains, I assume using the same mail server, and emails can't go from one domain to another within the same account.

Then there's the problem with web forms! Using ColdFusion and the cfmail tag on a website hosted on Jodohost, it seems that if the "to" address is on Jodohost mail servers, the email is never received. You can CC or BCC to non-Jodohost emails with no problem, and if you set the "to" address to a non-Jodohost address it goes through. So obviously the Jodohost SMTP server is processing the email. And this happens whether you have the cfmail tag's server, username, and password attributes set or not.

So, am I and my clients the only ones with these email issues. or have others experienced it? Are there fixes for this, some setting to check in the account, etc.? If this is unique to me and my reseller account, I'll send a ticket and try to work it out. But if this is common, perhaps some fixes posted here will help others in the future.
 
Please send us ticket with mention all information then we will check it.
 
We've experienced the exact same issues on WinCF2 & WinCF3. The problem is so sporatic that's it's really hard to guage where the breakdown is. It will work great for weeks or even months, then suddenly stop sending messsages and I don't know until a client calls to yell about it.

We have some test CFM scripts setup and those process fine (to non JH e-mail addresses) and it's a hit-or-miss whether it will send to a JH address. The biggest issues for us is that some of these clients have e-commerce sites that are attempting to process orders, so a customer pays but the client doesn't receive the order form and it makes for a very unpleasant tech support call.

We have tried using "localhost" and are now using SMTPAuth as instructed by support. I must say, we haven't seen much of a difference. I relaly hope they can find and correct this "bug" or server communication issue soon or we'll be losing a few CF clients in the very near future.
 
That's kind of why I'm hesitant to bother with a ticket. It's one of those things that you never know when it will happen, and it's hard to duplicate it for testing.

I've got probably 20-30 forms running using cfmail, on every CF server except the new CF7 server. Some work without a hitch, some are like described above - don't know it's broke til someone complains. I'm thinking it's not really a cfmail or even a CF problem, but something to do with the mail servers. Since the cfmail obviously processes to send the emails to non-JH addresses, it must be working. Plus, part of the problem is that emails sent using Outlook, T-Bird, etc. also get "lost", and that's totally outside of CF.
 
I opened a ticket 7+ hours ago and I'm on live chat right now. They keep telling me that the SMTP server issue has "been resolved" - but it is not. Something is terribly wrong and I hope they fix it quickly or I'm in big trouble.

My CFMail script tests are no longer working to emails sent to non-JH addresses like they were previously (yesterday), so the problem has worsened. I jave tried from at least three different domains and the forms are submitted successfully, but no mail every arrives. Good Oyster, we can't be the only two experiencing this issue.

I have asked for this issue to be escalated to a senior sys admin because JH support staff continues to say "issues has been resolved - please check now". I have asked them to check the CFMail logs for errors. I'll try to report back when I get a response from Mohit (livechat).
 
Just came upon this thread and checked a client's site. Mail to non-Jodo domains was not going out from his tell-a-friend and contact forms. But, I hadn't enabled SMTP Authentication (didn't need to when I created his site). I enabled it and now mail is sending to jodo and non-jodo accounts.

Tim
 
Just came upon this thread and checked a client's site. Mail to non-Jodo domains was not going out from his tell-a-friend and contact forms. But, I hadn't enabled SMTP Authentication (didn't need to when I created his site). I enabled it and now mail is sending to jodo and non-jodo accounts.

Tim

That is probably one of the most common reasons, with SMTP Auth it should work without any problem to anywhere.
 
Just came upon this thread and checked a client's site. Mail to non-Jodo domains was not going out from his tell-a-friend and contact forms. But, I hadn't enabled SMTP Authentication (didn't need to when I created his site). I enabled it and now mail is sending to jodo and non-jodo accounts.

Tim

Where do you enable SMTP Authentication?
 
You add the username and password attributes to your cfmail tab. Like this:

<cfmail
to="to_address"
from="from_address"
subject="subject"
server="mail.example.com" username="[email protected]" password="the_password">
<cfmailparam name="Reply-To" value="from_address">
<cfmailparam name="Message-ID" value="<#CreateUUID()#@example.com>">

Tim

PS: the two cfmailparams help your mail look more legit and less like spam
 
Thanks, Tim. I tried it, but it still does the same thing. After several emails and tests with tech support, it appears that all the copies sent to a Jodohost account were being marked as SPAM and deleted.

The main problem appears to be DSPAM. According to tech support, the messages from the form look too much like phishing /419 type emails. It's also showing the delivering host has no rDNS.

Now, I find this pretty silly. The host DNS and the recipient DNS are both Jodohost! Also, below is a sample of the content of the emails being sent:

The following person has requested information:
Name:Gary
Address: 123 Four Wheel Dr
Apt./Suite:
City: Miami
State/Province: FL
Zip/Postal Code: 33333
Phone: 305-555-6666
Email: ma****ng@w****0.com
Comments:Another test using the cfparams

This is text, no html. No images. No links. No foreign phone numbers, addresses, zip codes, etc. None of the earmarks of phishing or 419 emails. If it's something in the headers, who controls that? Why, Jodohost, of course! It is JH sending, receiving and marking as SPAM within its own mail system.

GMail, which has some of the best spam filtering I've ever used, doesn't even burp at these messages. Something isn't right.
 
DSPAM supposedly just marks the messages, and your control panel spam settings determine what is done with those messages. So, have you tried whitelisting your form-sender's address?

I have CF and PHP sending out "contact us" form results that look nearly identical to what you posted. They seem to be going through for me. So, I don't think I believe their answer that the forms look like phishing emails. Sounds like something else is going on there.

Also, have they told you if certain headers are missing? If so, you can add them with the cfmailparam tag.

I've pretty much given up CF development in favor of PHP. 99% of my stuff now uses the open source phpMailer for sending mail. Perhaps that's why I haven't encountered the same problems. phpMailer might be packaging the mail better so it looks less like spam that CF???

Tim
 
I have at least 20 other such "Contact Us" forms using the same cfmail tag and the only real difference is the domain names. All of those forms work fine, no spam issues to any accounts. Some of them do not even have server, username or password attributes! So it's the inconsistencies in the whole thing that bother me the most. If it works for one website, it should work just as well for other websites using the same email system. I have to believe it's a mail server/spam filter issue, as the cfmail tags are doing their jobs, evidenced by the successful emails being sent to other non-JH email addresses.
 
... it's the inconsistencies in the whole thing that bother me the most. If it works for one website, it should work just as well for other websites using the same email system. I have to believe it's a mail server/spam filter issue, ...

I've had exactly that problem today with a client. One test mail from one domain gets through, and an identical test mail using a different domain in the From line gets flagged as spam by dspam.
The two domains are on the same JH account, and the mails were sent through the same ISP account within seconds of each other to the same JH address.

dSpam simply is not doing a good job. When the spam is good enough to look like normal mail, training your spam filter with it simply trains it to show too many false positives. Perhaps it needs to be trained with a similar amount of non-spam mail so it can determine which factors are different. Looking at the factors it's taking into account, it appears that mail having today's date, using standard fonts, and having normal email headers are being weighed far too heavily. These elements are in non-spam mail as well, and that's why it cannot discriminate one from the other.

Most of my clients have asked me either to turn it off or turn it down to the point where it's just not useful any more.
 
I've had exactly that problem today with a client. One test mail from one domain gets through, and an identical test mail using a different domain in the From line gets flagged as spam by dspam.
The two domains are on the same JH account, and the mails were sent through the same ISP account within seconds of each other to the same JH address.

dSpam simply is not doing a good job. When the spam is good enough to look like normal mail, training your spam filter with it simply trains it to show too many false positives. Perhaps it needs to be trained with a similar amount of non-spam mail so it can determine which factors are different. Looking at the factors it's taking into account, it appears that mail having today's date, using standard fonts, and having normal email headers are being weighed far too heavily. These elements are in non-spam mail as well, and that's why it cannot discriminate one from the other.

Most of my clients have asked me either to turn it off or turn it down to the point where it's just not useful any more.

Sorry but this is not dspam, dspam never deletes ANYTHING.
SpamAssassin is the only thing that will prevent delivery.
Dspam is being blamed for a lot when it is not the cause in most cases. I have gone to not using spam assassin at all on a few of my domains and that ensures even if a message is marked as spam that is not a spam, that any attachment will not be mangled etc(this is hard to tell someone how to undo)
I have instead setup filters to look for the dspam headers on the LOCAL PC and move to a possible spam folder for manual sorting, it works great and no problems ever.
 
Sorry but this is not dspam, dspam never deletes ANYTHING.

I didn't say it did. If dspam thinks a mail is spam, Spamassassin gives it a whole 7.0 pts for that reason alone. That means Spamassassin treats it as spam in 'normal' mode, even if it sees nothing else wrong with the mail, and it then does whatever it normally does with spam; delete it or mark it or whatever.

dspam is currently marking stuff as spam for no good reason, and that is creating a lot of false positives because the score Spamassassin associates with that header is too high.

Most people aren't knowledgable enough to figure out message rules that look at the dspam headers.
 
Sorry but this is not dspam, dspam never deletes ANYTHING.

I didn't say it did. If dspam thinks a mail is spam, Spamassassin gives it a whole 7.0 pts for that reason alone. That means Spamassassin treats it as spam in 'normal' mode, even if it sees nothing else wrong with the mail, and it then does whatever it normally does with spam; delete it or mark it or whatever.

dspam is currently marking stuff as spam for no good reason, and that is creating a lot of false positives because the score Spamassassin associates with that header is too high.

Most people aren't knowledgable enough to figure out message rules that look at the dspam headers.
 
I didn't say it did. If dspam thinks a mail is spam, Spamassassin gives it a whole 7.0 pts for that reason alone. That means Spamassassin treats it as spam in 'normal' mode, even if it sees nothing else wrong with the mail, and it then does whatever it normally does with spam; delete it or mark it or whatever.

dspam is currently marking stuff as spam for no good reason, and that is creating a lot of false positives because the score Spamassassin associates with that header is too high.

Most people aren't knowledgable enough to figure out message rules that look at the dspam headers.

If it is scored wrongly by dspam then you will need to report it as such for correction. However I have checked a number of issues that people thought was dspam but it was indeed marking correctly and only spamassassin was thinking it was spam on other criteria.
 
I am in the exact same boat as Good Oyster and 68shelby in which some of my CF mail forms work and some do not. Currently my CF mail tag is set up as follow based on recommendations:

<cfmail to="to_address" from="#from_address#" bcc="bcc_address" subject="#form.subject#" server="mail.******.com" username="username@******.com" password="******" timeout="90" type="html" charset="iso-8859-1">
#form.message#
<cfmailparam name="Reply-To" value="#form.emailaddress#">
<cfmailparam name="Message-ID" value="<#CreateUUID()#@example.com>">
</cfmail>

However, it has been set up as follow:

<cfmail to="to_address" from="#form.emailaddress#" bcc="bcc_address" subject="#form.subject#" server="username@******.com:mypassword@mail.******.com" timeout="90" type="html" charset="iso-8859-1">
#form.message#
</cfmail>

Both give the same results. I have found that whenever I'm sending to a JH domain (username@******.com), the email will never arrive. Even if there are multiple names listed, weather it is multiple to names or a mix of to and bcc, the email will not arrived to anyone. However, when the JH domain email is removed, the email is sent to everyone and arrives fairly quick.

I have been testing for the past 2 days now and I have mixed and match the names in each of the send fields (to,cc,bcc). What I have found is that 100% of the time, whenever a JH domain email is included, the mail never arrives. I tested the same email, by sending the same subject and body, only incrementing a number after the subject to know what was done and wrote down all my test. In each of the emails that did not have a JH domain, the emails has arrived to all that it was sent to no matter the position for multiple names, or the field (to,cc,bcc). However, I have yet to receive any emails to any address whenever a JH domain was included. I tried different positions and different fields (to,cc,bcc) and each time, my code works on the page, but the email never arrives.

Is there an issue in which CF will not send an email to the same domain it is from or is there something in the mail server blocking the emails. My clients have been telling me that for some reason they don't get all of the emails and now I think I know why. My site is hosted on the WinCF server which is different from Good Oyster and 68Shelby yet we are all having the same problem.

Should I open a trouble ticket or is this already open by either Good Oyster or 68Shelby?
 
Ok, I've done even more testing and I'm still getting the same results. Whenever a JH domain email address appears in the sending fields (to,cc,bcc), no one receives the email. I've tried this both with a JH domain email only, and a mix of outside accounts (yahoo, gmail, etc) and a JH domain email. However, if I remove the JH domain email and only send it to a yahoo, gmail, etc account, the email arrives in about 30 seconds.

I also went through Horde and tried to send an email from one user to another withing the same JH domain, and would you believe it, I have not received the email. This is unacceptable. Going from a JH domain email to and outside email or vice versa work just fine.

Is there some kind of filter or blocker that is preventing email from being sent and received from a JH domain. I opened a ticket (FXZ-57467-822) stating what my findings where.

Please take a look at this as I can see this is going to cause me a lot of grief trying to explain to my customers that they cannot use their domain email.
 
Ok, I've done even more testing and I'm still getting the same results. Whenever a JH domain email address appears in the sending fields (to,cc,bcc), no one receives the email. I've tried this both with a JH domain email only, and a mix of outside accounts (yahoo, gmail, etc) and a JH domain email. However, if I remove the JH domain email and only send it to a yahoo, gmail, etc account, the email arrives in about 30 seconds.

I also went through Horde and tried to send an email from one user to another withing the same JH domain, and would you believe it, I have not received the email. This is unacceptable. Going from a JH domain email to and outside email or vice versa work just fine.

Is there some kind of filter or blocker that is preventing email from being sent and received from a JH domain. I opened a ticket (FXZ-57467-822) stating what my findings where.

Please take a look at this as I can see this is going to cause me a lot of grief trying to explain to my customers that they cannot use their domain email.

are you getting any bounce or message during smtp transmission?
 
Back
Top