I run three Magento web stores. All the orders e-mails are working just fine, with the exception of 7 e-mails that didn't even got sent from the webserver. Upon investigating the issue I discovered the following logs:

Magento log:

2013-08-08T11:44:59+00:00 ERR (3): 
exception 'Zend_Mail_Transport_Exception' with message 'Unable to send mail. ' in /var/www/website.com/lib/Zend/Mail/Transport/Sendmail.php:137

Postifx log:

Aug  8 12:44:59 bv-webserver postfix/sendmail[18647]: fatal: sales@website.com(33): No recipient addresses found in message header
Aug  8 12:44:59 bv-webserver postfix/postdrop[18648]: fatal: uid=33: malformed input

This is very strange, because hundreds of e-mails were sent just fine and only these 7 got this exception. In some cases the clients just purchased again from the store and then received the e-mail as expected.

I thought it could be a resource problem. But I run the newrelic agent and the server is at 20% load at most during peak hours (both memory and processors).

Edit: Forgot to mention, I run nginx with php-fpm.


postdrop[18648]: fatal: uid=33: malformed input

This say it all, you have 7 emails that are broken. They probably have a line feed/carrier return , making the headers finish too soon (probably before the To: header).

That line feed might be in the start of the recipient address (so the to: is null) or on in any previous user input strings. That line feed might also not be visible in many situations (stripped, form without scrool bar, replaced by space on output, etc), so search carefully.

try checking the /var/spool/postfix/maildrop/ folders for the bad emails, it should be empty, but give it a try...

you probably need to put postdrop in debug, add a -v in the end of the postdrop line in the master.cf

check the postdrop man page for more info

  • Obrigado, I'll try to search for something that might be altering the email address input. The maildrop folder is indeed empty. – Pedro Peixoto Aug 13 '13 at 14:53
  • don't forget the postdrop -v (or even postdrop -vvv) in the master.cf and restart the postfix... it might give you more info. You can also pickup the sendmail command, move it to sendmail.orig and create a script with cat - | tee /tmp/$(mktemp -t sendmail.XXXXXXX) | sendmail.orig $* . This will catch the new emails and save it to /tmp/sendmail.* – higuita Aug 13 '13 at 15:25

Clearly those seven orders were lacking a recipient e-mail address. Check if it's somehow possible to place an order in your web store without providing an e-mail.

  • I think Janne's answer is perfect, just remember to ensure you're checking that mail addresses can't have spaces or other illegal characters as well.. – NickW Aug 12 '13 at 15:10
  • One of the recipients of e-mail is always the same, it's set on Magento configuration (it's in bcc). The other one is a required field in the order form. I can see the e-mail when checking the order on the backoffice so they're really inputing an e-mail address. – Pedro Peixoto Aug 12 '13 at 15:16
  • And yes, I just checked the orders where this error was thrown and the client e-mails are in the right format with no illegal chars. – Pedro Peixoto Aug 12 '13 at 15:18
  • If you have a long day of debugging behind, please double-check everything tomorrow. :-) I'm still pretty sure that there is something wrong with the order form / Magento itself. – Janne Pikkarainen Aug 12 '13 at 15:34
  • I do. Hehe. But the problem with that logic though, is that I have hundreds of orders going through and only 7 emails bumped in this problem. The only thing changing is indeed the e-mail address. But in one case (at least), the client noticed he didn't receive the e-mail confirming the order, and purchased again, with the exact same items and e-mail address, and it worked as expected the second time around. – Pedro Peixoto Aug 12 '13 at 15:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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