intermittent issue with sending emails

[amart79196]

Hey Everyone...Here is the classic NIGHTMARE problem...

Sometimes, and this happens only sometimes, there will be a problem we me messaging a customer of mine. On top of the screen will flash pink telling me the error (basically the same info as I will type below). Also, I will get a white screen with a description of the error, but, unfortunately it doesn't point me in the proper direction in order to fix the problem.

These are some of the issues that I have seen:

EMAIL ERROR: THE FOLLOWING FROM ADDRESS FAILED: [email protected] (THIS EMAIL ADDRESS IS MY EMAIL ADDRESS) : MAIL NOT ACCEPTED FROM SERVER, 530, AUTHENTICATION REQUIRED.

SMTP SERVER ERROR: AUTHENTICATION REQUIRED
SMTP SERVER ERROR: AUTHENTICATION REQUIRED

-----------------------------------------------------------------------------------------------------------------------------------

This is for the most part when I do encounter this problem the error message that will show up. This doesn't happen all of the time, but it does happen sometimes.

I have tried rechecking all of the settings in zencart as they are all correct and again, it does work 80% of the time.

I am wondering if there is a solution for this?

Or better yet, is there a way I can get a more detailed log of this issue so I can get this to my hosting company to possibly find a solution to the problem. I'm afraid that without something very detailed, then I cant trace exactly where this problem is happening.

Any help on this matter is very greatly appreciated.

Thanks in advance!

[RodG]

Hey Everyone...Here is the classic NIGHTMARE problem...

It sure is. Intermittent problems are always the most difficult ones to solve.

However, I'm going to go out on a limb here with a bit of speculation, and a suggestion that many people probably won't like.

First the speculation... Based on the error message, it looks like under the e-mail options you have opted to use SMTP or SMTPAUTH, and the fact that it works most of the time would suggest that in spite of the error message, the authentication data is actually correct. This would therefore imply that on the occasions that the emails fail with an authentication error that there may have been a problem retrieving this info from the database. As I say ... speculation.....

Now for the suggestion - if the speculation is correct, one possible 'solution' would be to simply remove this authentication requirement, and this is easily achieved by opting to use the PHP or sendmail transport method rather than SMTP. Neither of these methods require authentication (which is one of the reasons they are often frowned upon), but nonetheless they are still safe to use. The main benefit of SMTP is less chance of the emails being rejected by the recipients servers,

In the absence of further clues (or better advice) I think this approach is worth a shot - It isn't going to fix the *cause* of the problem but it could alleviate these symptoms, and It's a little better than doing *nothing*, at least IMO.

Cheers
RodG

[mc12345678]

Realize that this doesn't directly answer the request, or more specifically doesn't offer the file and line number in which to provide a solution, but if you do want to obtain troubleshooting information to solve the problem and provide something to your host, my suggestion would be to follow the code for sending email using the transport method selected (as RodG inferred this would be SMTPAUTH or SMTP) and before the point where the email is pushed to the server, log applicable information (can use a trigger_error type command) and then in the section reporting the error (can use developers tool kit to find the area) log any response information. These files then could be used to speak with the host. In the interim and to allow business to continue, do as RodG suggests. Not all methods of communication are fully supported by all hosts.

In this case there may be multiple host computers handling email transactions and it could be that this one server is "not right". So by logging both good and "bad" transactions, the host may be able to narrow down the issue.

Perhaps there is a timeout that is occurring also, and that some setting needs to be changed to accommodate. Word of note/caution, the failure of the email to be sent as a result of a problem connecting to the host could also impact the completion of a sale. Such an error if occurring during the final processing could stop the process and cause the order information not to be captured by ZC.

[amart79196]

if the speculation is correct, one possible 'solution' would be to simply remove this authentication requirement,

Thank you for your suggestions. My mail host doesn't allow for unauthenticated emails so I must use SMTPAUTH.

log applicable information (can use a trigger_error type command) and then in the section reporting the error (can use developers tool kit to find the area) log any response information. These files then could be used to speak with the host.

How exactly do I do this??

Thank you BOTH in advance!

[RodG]

Thank you for your suggestions. My mail host doesn't allow for unauthenticated emails so I must use SMTPAUTH.

Basically, very few, if any, hosts allow unauthenticated emails, but this does NOT mean that you have to use SMTP or SMTPAUTH with your website. The webserver process itself runs as a valid authenticated user on the system that it is running, meaning that use can use the PHP or sendmail methods *without* any *further* authentication.

In other words, unless you know that the PHP or sendmail methods *don't* work (and I will be very surprised - even shocked if this is the case) then the very least you should do is *try* the suggestion rather than just outright stating that it won't work.

Originally Posted by mc12345678
log applicable information (can use a trigger_error type command) and then in the section reporting the error (can use developers tool kit to find the area) log any response information. These files then could be used to speak with the host.

How exactly do I do this??

Sorry, I don't know. I'm still having a little bit of trouble decoding the suggestion. ;-)

Cheers
RodG

[mc12345678]

Thank you for your suggestions. My mail host doesn't allow for unauthenticated emails so I must use SMTPAUTH.




How exactly do I do this??

Thank you BOTH in advance!

Basically, very few, if any, hosts allow unauthenticated emails, but this does NOT mean that you have to use SMTP or SMTPAUTH with your website. The webserver process itself runs as a valid authenticated user on the system that it is running, meaning that use can use the PHP or sendmail methods *without* any *further* authentication.

In other words, unless you know that the PHP or sendmail methods *don't* work (and I will be very surprised - even shocked if this is the case) then the very least you should do is *try* the suggestion rather than just outright stating that it won't work.



Sorry, I don't know. I'm still having a little bit of trouble decoding the suggestion. ;-)

Cheers
RodG

So as RodG has kindly pointed out before, sometimes my mind and my fingers fight each other for attention. :)

Theory is this: communication is a two way street. Server has to talk to email to authenticate and provide message, email has to talk back to indicate authorization and some sort of status (OK got message, can't send, etc.)

In the two way communication the email system gives up a little something, the details of which I haven't looked into, but the thought is that there should be some unique identifying information that may be beneficial to the host in resolving the issue. So, to that end, logging of information related to the transaction may help the host. Of course we all know they are most likely to deny any issue, but providing them the information may cause it to get resolved.

So, to log information and not stop program execution by logging that information, one can use a php function called trigger_error(data_to_log, status_code). The php manual suggests that the status_code can be omitted and execution will continue, but it is also good to take control of one's destiny. :) Ideally again one would log successful information as well as when the error occurs to provide/assess what the issue is that is causing the trouble. Again, haven't looked into what data to log, whether it is $_SESSION data or something else. So an example of code would be:

 trigger_error($_SESSION, E_USER_WARNING);

and this could be placed in the code stream where the error is generated as well as "after" the error handling for when the message is successfully "received".

Finding that location is now the "tough" part. There is email code at least in 1.5.5 under the vendors folder that in a recent search of email related operations I thought applied.

Hopefully that at least cleared up the thought behind my post, even if only a single step forward in a perhaps lengthy walk. :)

[amart79196]

Thanks for the replies....

I'm not sure if this is coincidental or not, but I lowered the servers PHP from 5.6 to 5.5 and I have not experienced it error since the change.

Is that just luck or did that have something to do with my issues?

[DrByte]

Thanks for the replies....

I'm not sure if this is coincidental or not, but I lowered the servers PHP from 5.6 to 5.5 and I have not experienced it error since the change.

Is that just luck or did that have something to do with my issues?

That could suggest that the server's master PHP configuration for the new version didn't have the proper settings for authenticated email in it.

It could also suggest that it's becoming urgent for you to upgrade your Zen Cart version since it contains modernized email handling capabilities that will work more effectively on servers using newer PHP versions.