Forgotten Password Email Not Working for Customer

[sparrowce]

I have been reading over the threads here related to issues where the forgotten password email is not being sent to customer, and so far no luck in resolution. Like others have mentioned, ONLY the forgotten password email is not coming through. I got my account notification email fine and do see the email archive in database captured the forgotten password email record, but nothing in my email. Am not using gmail, have checked junk folder, though other zen cart emails come thru ok. I am in demo of 1.54, still trying to work out some things before switching off the live 1.39h store. So I am the 'customer' at the moment not getting forgotten password email. Any ideas or tips? Thank you.

[mc12345678]

Email transport method? (PHP, smtpauth, etc?)
Send from known email settiing?

[RixStix]

If you install the "Email archive manager", you have the ability to see all the emails that were transmitted by zencart.

[sparrowce]

If you install the "Email archive manager", you have the ability to see all the emails that were transmitted by zencart.

Installed this, thank you. Here is the weirdest thing. I have been testing this for a couple of weeks and now it is working. Have tried it with 'send emails' in admin set to true, and also set to false (temp set to false to eliminate numerous admin emails while working thru configurations, add-on's, testing, etc.). It so far had not worked regardless of that setting. Today, after posting this and installing the email archive manager, and testing again, now I am getting those emails. To my knowledge, I have not changed any settings over the week that I'm aware of. 'send emails' in admin is set to true. I have no idea what I've done or not done to affect this and am just glad it is working now.

I do have a question about the email archive manager. I like it, it is very nice. Question is, when I re-send the password reset email from archive manager (was to test what that function did), it sent the email in code format, ie:
$EMAIL_SUBJECT

_html_ _head_ _meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /_ _base href=" . . . . . . .

I am not sure if that functionality would be used, but how can I change that format so it matches the html format of other emails?

Thank you.

[sparrowce]

Email transport method? (PHP, smtpauth, etc?)
Send from known email settiing?

Sorry . . . PHP transport method. Yes, known domain. Is there a difference in how password reset emails are sent than other emails? Am not sure why others work but password one does not. Also, I am currently using PHP 5.2 for demo due to 5.3 breaks live 1.39h store, and am using the workaround in 1.54 tips for 5.2. Soon as I can get demo working on all counts, will switch it to being live and up the php. However in 1.39h store, under same php, password reset emails are working fine with same settings. Please let me know what other info is needed, thanks.

[mc12345678]

Sorry . . . PHP transport method. Yes, known domain. Is there a difference in how password reset emails are sent than other emails? Am not sure why others work but password one does not. Also, I am currently using PHP 5.2 for demo due to 5.3 breaks live 1.39h store, and am using the workaround in 1.54 tips for 5.2. Soon as I can get demo working on all counts, will switch it to being live and up the php. However in 1.39h store, under same php, password reset emails are working fine with same settings. Please let me know what other info is needed, thanks.

So, I'm assuming that although email manager may not be installed making review of emails generated by ZC easier to review that based on the original post you have verified that ZC recognzes/logged that the password reset email was generated and "sent". At that point, ZC has nothing further to do with the email itself. But, based on information contained in the email (headers) other systems downstream may be otherwise dumping the email...

If up to this point I am wrong, then need to address verifying that the email is being pushed to the internet through the tools above or other tools. If so far all is correct, then by changing the transport method to one a bit more "trusted" (by having to provide credentials) the method may provide the type of information in the email to allow it to continue through the process once leaving the store...

[sparrowce]

So, I'm assuming that although email manager may not be installed making review of emails generated by ZC easier to review that based on the original post you have verified that ZC recognzes/logged that the password reset email was generated and "sent". At that point, ZC has nothing further to do with the email itself. But, based on information contained in the email (headers) other systems downstream may be otherwise dumping the email...

If up to this point I am wrong, then need to address verifying that the email is being pushed to the internet through the tools above or other tools. If so far all is correct, then by changing the transport method to one a bit more "trusted" (by having to provide credentials) the method may provide the type of information in the email to allow it to continue through the process once leaving the store...

I must have been posting my update that it is working now before seeing your post. Yes, that was happening. For whatever reason now, it is working and I've installed the email archive manager, which is extremely nice, with the exception of the one question I just posted about the 'resend' email formatting.

Thank you for the help.