0

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: [email protected](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.

2 Answers 2

3

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

2
  • Obrigado, I'll try to search for something that might be altering the email address input. The maildrop folder is indeed empty. Commented Aug 13, 2013 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.* Commented Aug 13, 2013 at 15:25
0

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.

8
  • 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.. Commented Aug 12, 2013 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. Commented Aug 12, 2013 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. Commented Aug 12, 2013 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. Commented Aug 12, 2013 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. Commented Aug 12, 2013 at 15:41

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.