SMTP Mail Setup Creates 500 error on Submit

[ranwilli]

Thus far we built two simple forms on a Joomla 2.5.4 site using Fabrik (updated daily since we have been trying to squash this issue)...

We are on a generously sized cloud server and the form submission sits and cranks until a 500 Server error is generated. Apache error logs don't see this as an error. We had the Joomla config set to "SMTP" to get our emails to go through to a "G-Mail" email address... and the emails went through AND the db was updated, but there was no joy on the front end...

So mostly because I was out of other ideas for a solution, I switched Joomla to "sendmail", and all is well (email sent to non-GMail account).

unfortunately, I MUST use the SMTP...

Any idea what is causing the 500 error while the server is set to SMTP?

 

[cheesegrits]

At the risk of opening a can of worms ... any idea why The Goog is blocking your mail when it goes through sendmail?

Have you done an RBL check?

I can't immediately see why the SMTP method would cause a 500, unless your SMTP server is slow enough to run you over your PHP's max execution limit, which default to 30 seconds. How quickly does it come back at you with the 500 error?

There's very little Fabrik involvement when sending mail. We just put together the to, from, subject, message and attachment(s) list, and call J!'s sendMail() API method:

				// Get a JMail instance (have to get a new instnace otherwise the receipients are appended to previously added recipients)
				$mail = JFactory::getMailer();
				$res = $mail->sendMail($email_from, $email_from_name, $email, $thisSubject, $thisMessage, $htmlEmail, $cc, $bcc, $thisAttachments);

... and J! then does all the actual mail magic, depending on the mailer you have configured.

-- hugh




-- hugh

 

[cheesegrits]

OK, looking at the code in J!'s phpmailer, it's going to tell you "Error 500" if the mailer's parent::Send() method doesn't return 'true'. Which can be down to a lot of reasons, especially when driving an SMTP session by steam, which is what the SMTP method does. Which means there's a lot of to and fro'ing between client and server, going through the various steps of the SMTP handshaking and protocol, any one of which may return an unexpected response.

But the actual error won't ever get shown, because it gets echo'ed, rather than injected into J!'s session based messages queue (because J! have borrowed a public domain script rather than roll their own, and haven't tweaked it to use the J! error reporting API). So the implicit redirect at the end of our form submission will mean your browser never sees those errors.

So ... try this ... edit ./plugins/fabrik_form/email/email.php, around line 196 you should find the three lines I quoted in my previous post. Immediately after the sendMail line, put this:

exit();

... which should immediately terminate script processing. With any luck, what should happen is that any errors that were echo'ed by the phpmailer.php or smtp.php scripts in J! should then show on an otherwise blank page.

-- hugh

 

[ranwilli]

Thanks for that I will give it a try...

 

[ranwilli]

At the risk of opening a can of worms ... any idea why The Goog is blocking your mail when it goes through sendmail?

Have you done an RBL check?

...
-- hugh

I don't really know why, only that it is a pretty common situation for sites hosted in the cloud, using GMail as their email reciever... it is ONLY to our own domain that SMTP is absolutely necessary, although another Form program I used once said the SMTP protocol was better for sending form data (why that was escapes my memory at this moment).

I'd be delightted to do an RBL check, but I have no idea what that is.

Thanks for the help.

 

[ranwilli]

...

I'd be delightted to do an RBL check, but I have no idea what that is.

...

Googled it and ran it...

Everything is green meaning thare is no record of our IP being used for spamming...

 

[cheesegrits]

I don't really know why, only that it is a pretty common situation for sites hosted in the cloud, using GMail as their email reciever... it is ONLY to our own domain that SMTP is absolutely necessary, although another Form program I used once said the SMTP protocol was better for sending form data (why that was escapes my memory at this moment).

Well, all sending of mail uses SMTP, regardless of the method. SMTP (Simple Mail Transport Protocol) is the way mail is shipped around the 'net.

Of the methods that J! offers, the most preferably is sendmail. This uses the locally installed 'sendmail' program on your server, which means that you can see the full logs for the delivery, and easily track problems. You essentially "own" the process from beginning to end. The UNIX sendmail has a 30+ year development history, and is as solid as a mail delivery system can get. It also minimizes J!'s involvement in the delivery, as J! can just invoke the sendmail program through a local socket connection, hand it the mail, job done. Sendmail then handles all the queueing and retrying if the recipient's server is not available, etc.

The next best is SMTP. This involves handing the mail off to another server, usually the outbound relay provided by your host, for delivery to the recipient(s). That relay will then handle queueing, retries, etc. Slightly less reliable than local sendmail, as there's a lot more error prone conversation that has to go on between J! and the relay over the network. And you are very unlikely to have access to the relays logs, to track any delivery problems. Which is essentially the situation you are in now.

The absolute worst is PHP, because this involves J! itself contacting the recipient's mail servers directly, with no queueing or redelivery attempts. So if the recipient's mail server is down (say, being rebooted, or a network link is down, whatever), then the mail doesn't ever get delivered, period.

Anyway ... did you try putting that 'exit' in the our email plugin code?

-- hugh

 

[ranwilli]

I did, but got only a white screen (error reporting on server tab of globals set to "maximum")...

 

[cheesegrits]

So how long does it spin it's wheel for before tossing the error?

Also, when you say 500 error ... is that an actual browser error page, or a J! page with a 500 error warning at the top?

-- hugh