Contact forms working but with long delay - any ideas?

I’m setting up a contact form plug-in for the first time and have tried several - easy contact forms, fast secure contact form, visual form builder, contact form 7. With all the plug-ins, there is a 55-65 second delay between clicking ‘submit’ and getting the ‘successfully submitted’ screen. Messages submitted via the form do get to my email inbox with all the plug-ins, so the basic configuration seems ok, but that kind of delay is a pretty bad user experience.

Anyone have any ideas re what might be causing the problem? Any help/thoughts appreciated - thanks.

There is a nice Wordpress plugin that will switch all mail to SMTP. You could try that. You might want to make sure to use an email that matches your domain name ( I seem to remember DreamHost having some caveat about that)

Thanks. I tried the SMTP plug-in and it gave me this error for email addresses both matching and not matching my domain name:

SMTP server error: 5.7.1 : Recipient address rejected: Access denied

The long delay also is not affected by using an email matching the domain name. Delivery isn’t affected either; I read the many threads with the caveat about making sure the domain name matches, and the info gets delivered whether I match domain or not (in both “To” and “From”).

Suggestions much appreciated, others welcome. :slight_smile:

To me the original submit delay of almost a minutes sounds more like the apache glitch that no one seems to be able to solve permanently. Try opening a ticket and asking for that to be checked.

To use SMTP the email must be a valid email on your account, and the SMTP server does require login to that account via user/pass. I suspect the error message in this case has more to do with login to the mail server (i.e. “Access denied”) than it does with a problem with the recipient’s address.
Reading both your messages again: it’s the FROM header that must match your domain.

If your not yahoo/gmail/etc, you can’t send email as being yahoo/gmail/etc. Your outbound email MUST be from your domain. and if using smtp that address must exist on the mail server and you must provide the password so that the smtp plugin can login to that account.

Thanks LakeRat.

The plot thickens.

I’m having this delay problem with several contact form plugins in a wordpress installation in a subdomain ( where I’m building a site that’s not ready to display to the world.

On a lark I installed contact form plugins in a website I maintain at and also in the test version of that website, located at, where I try tweaks before editing the live site. Everything works beautifully in both places, with no delay.

I tried changing the following variables in the problematic installation:

  • turned off all plug-ins except the contact form
  • changed the theme to the same as the installations that work fine
  • changed all email info in the plugin settings (contact, return-path, etc) to be identical to the installations that work fine
  • even changed the Wordpress admin email to be the same as on the other installations

…and the problem remains, on that one installation only. Does that clarify where to go next? More likely to be the apache glitch you referred to? I’ll open a ticket, but am game to try other suggestions. Thanks.

Sounds even more like the apache glitch now. You ruled out the server, the plugin and proved the settings work fine.

Support seems to be able to clear up the problem (for at least a period of time) by doing something and then restarting the apache instance. But then it seems to come back. There are mentions in a lot of threads, but here is a long one that’s darn near a year old now:

Thanks - your perspective is really helpful.

DH Support got back to me within minutes, said my 3 sites’ processes/scripts were collectively exceeding allotted memory for a shared server, so they are getting killed by Procwatch (their process watcher). Maybe that’s why the delay was almost exactly 60 seconds each time. Sure seems odd for 3 tiny sites with almost no dynamic elements.

They recommended that I use shell access to identify which scripts are being memory hogs. Wish me luck - I’ve never used shell access, the wiki page on using ssh to find causes of heavy usage looks like Greek to me, and I can’t even find a username/password combo that gets accepted on the command line interface to establish shell access at all!

Thanks again.

User/pass is the same as your ftp/sftp etc user. BUT shell access must be enabled for the user in the panel. “Edit” the user to check and/or update.

Thank you so much! I’d gotten the shell access configured but forgot that I’d changed the FTP password to be different from my dreamhost login password long ago - my FTP client enters it automatically. Succeeded with your help!

Hi LakeRat -

Just wanted to say thanks for your help, I solved the problem. 2 DH Support people offered the diagnosis that my sites were collectively using too many resources, stating that WP is a memory hog, and directed me to many, many references on how to optimize a WP website, suggesting that the remedy was to optimize all the installations and then buy VPS if I can’t get the resource use down.

After wading through the optimization literature for a while, it still just didn’t make sense that their diagnosis was correct if I was having the problem on only one of 3 WP installations. So I just set up a new installation at, and everything works fine there. Contact form submissions are still delayed by 60 seconds in the installation at So it seems like something was just hosed in that installation, and the solution was to trash it and replace it, not spend hours on optimizing and ssh’ing.

Your thoughtful comments helped me remain suspicious of the advice from DH support and saved me lots of time following their fruitless directions. So I wanted to take a moment of that time to thank you! I hope you have a great Thanksgiving.

are you getting emails from procwatch? If stuff is getting killed by procwatch you should be getting automated emails about that.

Maybe DH_Elle s can figure out what the actual address of is and take a look at that apache instance.

I’m with you tho, I don’t think this is a procwatch problem, unless you are getting email (that you didn’t mention anywhere) and then there may be some relativity, but I think the real problem is whatever the apache glitch.

That’s… really a weird error. (Sorry, I try to be more on the spot checking in here, but it’s been weird the last couple weeks).

So what OTHER plugins are you running, out of curiosity? Did you test this out on a clean site? What’s the diff between subdomain3 and subdomain2? If subdomain3 works and it’s on the same server, subdomain2’s differences would be my first place to look.

[SOLVED] Thanks for checking in - appreciate it. I agree that the problem, whatever it is, must lie in that specific subdomain.

Since everything works fine just moving the site to another subdomain, and it’s a test site that could be anywhere, I’m working with the moved site and not worrying about subdomain2 anymore.

Thanks again!