Troubleshoot - Email Problems

From Zen Cart(tm) Wiki
Revision as of 06:33, 9 February 2008 by Swguy (talk | contribs) (Diagnosing Problems)
Jump to: navigation, search

Troubleshooting Email Problems in Zen Cart™

Zen Cart™'s email infrastructure is largely dependent on the services available to the computer operating as your webserver. This includes internet connection issues, available ports, as well as PHP configuration options and the programs/services running on your server.


Zen Cart™ Email Infrastructure Explained

Here's how it works:

  1. Admin and Store both use the same infrastructure.
  2. Zen Cart™ uses phpMailer for sending mail. (Prior to v1.3, Zen Cart™ used a mishmash of inherited code from osCommerce that met with mediocre success and needed a huge facelift. So we switched to the popular phpMailer option after testing on numerous sites using Zen Cart™ v1.2.5 thru 1.2.7.)
  3. Wherever an email is sent, it is initiated via zen_mail() which is in the /includes/functions/functions_email.php. This builds the email object according to all your settings in Admin > Config > Email options.
    • transport method: PHP, smtp, sendmail, sendmail-f, smtpauth, etc.
    • CR/LF settings
    • charset
    • mime type
    • sent to, sendfrom
    • ... everything from that section, really.
  4. Then it hands the email off to phpMailer to send it.
    • If the transport is "PHP", then the server's PHP configuration takes over entirely, using whatever PHP has been configured to use.
    • If the transport is a sendmail function, then the server attempts to use the sendmail program on your webserver.
    • If the transport is SMTP/SMPTAUTH, then direct communication with the specified mailserver is initiated.
  5. If email archiving is enabled, the email is stored to the archive table.

Done.

That's it.


Prerequisites

  1. Your webserver must have a mail service enabled. For Linux/Unix hosts, this is typically done via sendmail or exim or qmail daemons. On Windows™ servers, this may be done via services offered with IIS.
  2. Your webserver must allow email connections from PHP.
  3. If you are using sendmail options, then the PHP configuration for sendmail functions must be configured properly on the server.
  4. You must have an unrestricted connection to the mailserver you're sending through.
    • If you are running from a home-based server (ie: for testing), note that your ISP may automatically have port 25 blocked so that you have to send mail through their server. In this case, use SMTP for your transport method, and supply your ISP's mailserver as your SMTP host.
    • If your webhost mailserver is reachable on another port, supply that port number in the SMTP settings.


Diagnosing Problems

  1. change transport methods (ask your host what's best ... they should know how they've configured your server).
    • NOTE: PHP or sendmail-f and smtpauth are less likely to end up getting treated as spam.
  2. change send-from email addresses.
  3. change send-to email addresses ... DO NOT TEST USING FREE MAIL SERVICES ... your mail is often dropped to a junkmail spot.
  4. be sure there are no embedded carriage returns in your send-to email addresses (see http://www.zen-cart.com/forum/showthread.php?t=86423 for details)
  5. check your junkmail settings.
  6. research whether your mailserver or hosting company is blacklisted (you can check http://www.mxtoolbox.com/blacklists.aspx or google for smtp blacklist for additional resources)
  7. try setting the option for Emails must send from known domain? to true. This causes the email "sender" address to be more aligned to your own website, and thus less likely to be rejected while processing.
  8. check whether the email archives are showing the sent messages (there's an archive reader in the Downloads area under Admin Tools)
  9. try testing with MIME HTML emails OFF, since many spam filters block HTML-formatted messages before they even get out the gate.
  10. check the mailserver logs ... is it complaining about something, either inbound or outbound?
  11. for kicks, get the webserver/mailserver rebooted and dump all the logs ... just maybe something's runamuck in there ...
  12. Try enabling Email Archiving. Then grab the email archive reader from the Zen Cart™ Downloads section (in admin tools), and confirm that the emails are actually being sent from Zen Cart™. If it's in the archive, it was handed off to the mailserver. Once the email leaves Zen Cart™, it's at the mercy of your mailserver.
  13. Look at your raw/full email headers. Does the "from" address appear to be a "nobody@xxxxxxx" address? Some hosts block these. The "email must send from known domain" setting is designed to counteract this. The SMTPAUTH setting also helps to work around this.
  14. This is RARE: If using "sendmail" and your "sendmail" path on your webserver is not the default of /usr/sbin/sendmail then you can override the default by adding a definition for it in a new file on your server: /includes/extra_datafiles/email_sendmail_override.php ... create a define for EMAIL_SENDMAIL_PATH and point it to the actual sendmail path for your particular host. This should not be necessary, and usually using "PHP" as transport method will correct it without making this edit.
  15. Does your server require 7bit mail encoding instead of the default 8bit? If so, edit the /includes/extra_configures.email_use_8bit.php file and put // before the define statement there.

If the email doesn't get to its destination, then usually the problem is a misconfiguration of the MTA or the host is blacklisted somewhere, or ports are blocked or ... well ... the probable causes are for a system administrator to understand.


Questions for your Hosting Company

Have you asked your hosting company what the right configuration is for your server to send mail most appropriately?

As far as Zen Cart™ is concerned, you have these options. Ask your host what they require.

  1. Mail Transport ... select from PHP, sendmail, sendmail-f, smtp, smtpauth
  2. Emails must send from known domain ... true/false
  3. E-Mail Linefeeds ... LF for Linux/Unix hosts, CRLF for Windows hosts

If your "contact us" emails are not arriving at the desired destinations, try emptying the "contact us pulldown" list. This will force it to use your Store Owner email address and bypass the occasional confusion encountered with properly formatting addresses for the pulldown list.

As mentioned earlier, if the emails are showing in the archive log (assuming you've enabled it), then Zen Cart™ is generating the message and handing it off to your webserver to send. If it's not being delivered, then either your webserver is dumping it, or the recipient is not getting it, possibly due to frequent spam from your webhost or other reasons. Perhaps your hosting company will offer you some assistance or at least explain how their servers are configured so that you can determine the right setting for your hosting environment. They know your server better than anyone.

Ask your host whether your/their mailserver is blacklisted by anyone. If so, try to get the blacklisting removed.

AOL and Hotmail dump emails originating from server/client IP addresses that fail DNS reverse lookup. You should talk to your webhost to ensure that your webserver and hosting account / domain are properly configured with a PTR or DNS reverse lookup.

Using external SMTP mail servers

Some people prefer to use resources such as gmail or yahoo mail etc for sending their business emails. There are differing schools of thought about the merits of doing so. If you deem that this is the best practice for your business, the following information may be of help to you.

Yahoo Hosting

For those of you using Yahoo as a webhost doing a search in the Yahoo help pages for PHP/Perl set up may help. Also setting up a tmp file in your Yahoo account may shed a bunch of light on things and give you answers right away as to why the e-mail isn't sending.

  1. In your Yahoo control panel, check if the email address you are using is set as "Pop/Webmail", and not just "Mail Administrator". You may have to create a new one.
  2. the Zen Cart option Emails must send from known domain must be set to YES
  3. Yahoo Outgoing (SMTP) Mail Server: smtp.mail.yahoo.com
  4. SMTP Port 25

Google Gmail

Gmail wants an SSL/TLS connection, which is not offered by Zen Cart. Nevertheless, you may or may not have some success with the following:

Set up as SMTPAUTH, with your gmail username/password.

  • SMTP Host: smtp.gmail.com
  • SMTP Port 465 or 587

More technical information is available in Google's Help Center

You may have to have your host make some changes if you are using Google hosted mail.

GoDaddy Hosting Plans

If you have a GoDaddy hosting plan and plan to use it for sending emails from your Zen Cart site, you should check your email account list and set the "smtp relay transmissions per day" to the max of 250/day instead of the default of 0/day.


Preventing My Mail From Being Treated as Spam

The most common cause of email being treated as spam stems from how your webserver is configured to send mail. By default, PHP will appear as a user called "nobody@yourdomain.com" or something similar. Most spam filters will look at that and assume that those emails were generated by spam bots and thus the message is dumped without any further consideration.

Other causes include messages which have ALL UPPERCASE letters in their Subject field. Don't do that. You can usually set the subject line for individual emails in your Zen Cart language files.

  1. change your email transport method to "sendmail -f" or "SMTPAUTH". This will cause the messages to appear as they are coming from "you" instead of as coming from your server's PHP.
  2. the option 'Emails must send from known domain?' should be set to True. This will cause e-mail providers see that it is coming from some place legit and not filter it as spam. And, more specifically, your own webserver will not ignore it because it will now appear as legitimately coming from itself, rather than from a 3rd-party.
  3. AOL and Hotmail dump emails originating from server/client IP addresses that fail DNS reverse lookup. You should talk to your webhost to ensure that your webserver and hosting account / domain are properly configured with a PTR or DNS reverse lookup.