3

I've got a Magento 1.9.1 implementation and am having issues sending out order related emails.

I have checked cron jobs and AOE Scheduler reports core_email_queue_sendall and core_email_queue_cleanup are enabled and running.

I've setup system cron to run cron.php every 5 minutes.

But I'm still not receiving emails.

Upon checking the database tables, I actually see that all the order related emails (new orders, etc) are in core_email_queue. The 'processed_at' column has a value, indicating that the email has been processed.

Why don't I see the emails? Does having a 'processed_at' value indicate that the emails had already been sent out?

Improve this question

3 Answers 3

Reset to default
4

Have you checked your Magento logs yet? We recently had a client who reported the same symptom on their 1.9.1 installation. When we checked the Magento logs, we discovered that their system was making calls to a PHP module called mb_string() which were failing.

Fatal error: Call to undefined function mb_convert_encoding() in /public_html/lib/Pelago/Emogrifier.php on line 556

That mb_string() function is used in Magento 1.9.1 to strip out CSS styles from your email templates and inline them into your outbound email HTML code for supporting Mail Clients that won’t render CSS 3 styles : http://www.myintervals.com/blog/2014/12/02/magento-and-the-intervals-emogrifier-class/

Their web host did not have this PHP module installed / enabled, so the function calls were throwing errors before the logic that sends the actual message can be executed, causing emails to not be sent.

If your logs show a similar error, you may need to contact your web hosting provider to see if they can enable support for mb_string()

If they don't support it, you'll need to find another host who offers support for it if you want to continue running 1.9.1

If this error isn't being thrown in your logs, you may find one of the answers submitted in this discussion may apply : New order email confirmation not being sent

Improve this answer
2
  • I don't have the error that you've stated above. Thanks for providing some clues though!
    – alimjm
    Commented Apr 3, 2015 at 13:29
  • 1
    Just a quick update - it's your email SMTP / MTA that's dropping the emails or rejecting them. Magento uses the same functions to send emails regardless of the originating or the sending domain. I'd add this comment to your own answer, but I don't have enough karma yet to comment :) You could switch to another MTA / SMTP server, or figure out the configuration directive needed to allow it to send mail to itself without dropping the messages.
    – Bryan 'BJ' Hoffpauir Jr.
    Commented Apr 7, 2015 at 22:32
1

I seemed to have solved the issue by changing the "customer" email to a different domain from my magento store.

the email server on my server seems to be dropping emails originating from the cron queue when it sees an identical domain name to the store.

Does magento send email using a different function call when

  1. sending direct (e.g. account setup emails)
  2. sending the email through cron process

Would be cool if someone could explain this.

Improve this answer
1
  • Just a quick update - it's your email SMTP / MTA that's dropping the emails or rejecting them. Magento uses the same functions to send emails regardless of the originating or the sending domain. You could switch to another MTA / SMTP server, or figure out the configuration directive needed to allow it to send mail to itself without dropping the messages.
    – Bryan 'BJ' Hoffpauir Jr.
    Commented Apr 10, 2015 at 14:30
1

I had the same issue and found out that it was related to an extension. Fooman Email Attachments has now been updated to v0.10.4. Versions below v0.10.3 won't work with Magento 1.9.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.