'Zend_Mail_Protocol_Exception' with message '5.1.3 Invalid address

[pknap]

Hi,

I have this problem: Magento js validation lets users enter e-mails with polish accents in billing/registration/other forms where emails are used. When user creates order, email with accent is saved in core_email_queue_recipients, and when cron tries to send message to such e-mail address, it throws exception:

2015-11-03T08:51:12+00:00 ERR (3):
exception 'Zend_Mail_Protocol_Exception' with message '5.1.3 Invalid address
' in /var/www/xxx/lib/Zend/Mail/Protocol/Abstract.php:431
Stack trace:
#0 /var/www/xxx/lib/Zend/Mail/Protocol/Smtp.php(289): Zend_Mail_Protocol_Abstract->_expect(Array, 300)
#1 /var/www/xxx/lib/Zend/Mail/Transport/Smtp.php(211): Zend_Mail_Protocol_Smtp->rcpt('ąęą@poc...')
#2 /var/www/xxx/lib/Zend/Mail/Transport/Abstract.php(348): Zend_Mail_Transport_Smtp->_sendMail()
#3 /var/www/xxx/lib/Zend/Mail.php(1194): Zend_Mail_Transport_Abstract->send(Object(Zend_Mail))
#4 /var/www/xxx/app/code/local/Aschroder/SMTPPro/Model/Email/Queue.php(99): Zend_Mail->send(Object(Zend_Mail_Transport_Smtp))
#5 [internal function]: Aschroder_SMTPPro_Model_Email_Queue->send(Object(Mage_Cron_Model_Schedule))
#6 /var/www/xxx/app/code/core/Mage/Cron/Model/Observer.php(325): call_user_func_array(Array, Array)
#7 /var/www/xxx/app/code/core/Mage/Cron/Model/Observer.php(72): Mage_Cron_Model_Observer->_processJob(Object(Mage_Cron_Model_Schedule), Object(Mage_Core_Model_Config_Element))
#8 /var/www/xxx/app/code/core/Mage/Core/Model/App.php(1338): Mage_Cron_Model_Observer->dispatch(Object(Varien_Event_Observer))
#9 /var/www/xxx/app/code/core/Mage/Core/Model/App.php(1317): Mage_Core_Model_App->_callObserverMethod(Object(Mage_Cron_Model_Observer), 'dispatch', Object(Varien_Event_Observer))
#10 /var/www/xxx/app/Mage.php(448): Mage_Core_Model_App->dispatchEvent('default', Array)
#11 /var/www/xxx/cron.php(76): Mage::dispatchEvent('default')
#12 {main}

And if cron hits this e-mail it stops, and does not process queue further, so no e-mails after this get sent. It just stucks. Is there a way to validate e-mail addresses for accents in backend, or option to skip this e-mail if this exception occurs, or changing js validation is the only way?

[aschroder]

I'd probably change the JS validation, fence at the top of the cliff instead of ambulance at the bottom...

But the exception catching and recovery is a good idea too - does the queue pick up again next from invocation or it's stuck forever?

On Thursday, 5 November 2015, pknap [email protected] wrote:

Hi,

I have this problem: Magento js validation lets users enter e-mails with polish accents in billing/registration/other forms where emails are used. When user creates order, email with accent is saved in core_email_queue_recipients, and when cron tries to send message to such e-mail address, it throws exception:

2015-11-03T08:51:12+00:00 ERR (3): exception 'Zend_Mail_Protocol_Exception' with message '5.1.3 Invalid address ' in /var/www/xxx/lib/Zend/Mail/Protocol/Abstract.php:431 Stack trace: #0 /var/www/xxx/lib/Zend/Mail/Protocol/Smtp.php(289): Zend_Mail_Protocol_Abstract->_expect(Array, 300) #1 /var/www/xxx/lib/Zend/Mail/Transport/Smtp.php(211): Zend_Mail_Protocol_Smtp->rcpt('ąęą@poc...') #2 /var/www/xxx/lib/Zend/Mail/Transport/Abstract.php(348): Zend_Mail_Transport_Smtp->_sendMail() #3 /var/www/xxx/lib/Zend/Mail.php(1194): Zend_Mail_Transport_Abstract->send(Object(Zend_Mail)) #4 /var/www/xxx/app/code/local/Aschroder/SMTPPro/Model/Email/Queue.php(99): Zend_Mail->send(Object(Zend_Mail_Transport_Smtp)) #5 [internal function]: Aschroder_SMTPPro_Model_Email_Queue->send(Object(Mage_Cron_Model_Schedule)) #6 /var/www/xxx/app/code/core/Mage/Cron/Model/Observer.php(325): call_user_func_array(Array, Array) #7 /var/www/xxx/app/code/core/Mage/Cron/Model/Observer.php(72): Mage_Cron_Model_Observer->_processJob(Object(Mage_Cron_Model_Schedule), Object(Mage_Core_Model_Config_Element)) #8 /var/www/xxx/app/code/core/Mage/Core/Model/App.php(1338): Mage_Cron_Model_Observer->dispatch(Object(Varien_Event_Observer)) #9 /var/www/xxx/app/code/core/Mage/Core/Model/App.php(1317): Mage_Core_Model_App->_callObserverMethod(Object(Mage_Cron_Model_Observer), 'dispatch', Object(Varien_Event_Observer)) #10 /var/www/xxx/app/Mage.php(448): Mage_Core_Model_App->dispatchEvent('default', Array) #11 /var/www/xxx/cron.php(76): Mage::dispatchEvent('default') #12 {main}

And if cron hits this e-mail it stops, and does not process queue further, so no e-mails after this get sent. It just stucks. Is there a way to validate e-mail addresses for accents in backend, or option to skip this e-mail if this exception occurs, or changing js validation is the only way?

— Reply to this email directly or view it on GitHub https://github.com/aschroder/Magento-SMTP-Pro-Email-Extension/issues/134 .

[pknap]

Hi, thanks for replying.

It's stuck forever - Magento tries to send first message over and over again and does not jump to second and next messages. That's why I think exception catching is necessary, since someone evil could easily disable all your order e-mail delivery bypassing frontend validation.

[aschroder]

Yeh, agreed. I’ll take a look a this in the next release - seems it’d be a good feature to yank failing emails out of the queue (and maybe notify the admin).

On Thu, Nov 5, 2015 at 5:54 AM, pknap [email protected] wrote:

Hi, thanks for replying.

It's stuck forever - Magento tries to send first message over and over again and does not jump to second and next messages. That's why I think exception catching is necessary, since someone evil could easily disable all your order e-mail delivery bypassing frontend validation.

— Reply to this email directly or view it on GitHub https://github.com/aschroder/Magento-SMTP-Pro-Email-Extension/issues/134#issuecomment-153829178 .

[jg-development]

+1

[alexwatever]

Came across this issue today, improper validation by our checkout(didn't remove a space) caused SMTP Pro to continuously retry the email which prevented the queue from processing. Disabling the queue in config allows any new emails to be sent.

On a side note it worked in my favour. I'd been lazily putting off setting up mandrill so it forced my hand. Thanks for the great work.

[melaxon]

It happened to me a few times. I disabled the module within app/etc/modules/Aschroder_SMTPPro.xml thus switching to php mailer and all queued messages were being sent right away. And then re-enabled the module again. To reproduce the problem you can place order using some not-existing email address. Last time it happened when I placed test order using [email protected]

But I noticed that frontend messages from contact form were delivered normally, only order notifications were queued forever (magento 1.9.2.1)

[juanune]

I ran into this problem today, as somebody had put an improper email address into the system. Although this was fixed in a matter of minutes, its presence caused a chain reaction that caused ~500 emails to get blocked over a day.

For others who stumble across this, I couldn't set things to use sendmail (which one of several reasons we use the plugin in the first place), so I hard to temporarily hard-patch the code.

On line 61 of Queue.php -- right after the list() construct -- just put in a quick fix:

if ($email == '[email protected] om')
{
   $email = '[email protected];
}

Once you're done, you should remove the code to stay 'clean'.

[r0bin]

In the shop of one of our customers the mails were stuck since 1st of August and we've just come across this problem.

I think it's a pretty severe issue if someone is able to break a shop as easily as that by just submitting an invalid mail address.

[jg-development]

I think we should handle it like Magento itself. They always set the mail as processed, even if an error is thrown. https://github.com/speedupmate/Magento-CE-Mirror/blob/master/app/code/core/Mage/Core/Model/Email/Queue.php#L246 I vote for the pull request of @vsushkov https://github.com/aschroder/Magento-SMTP-Pro-Email-Extension/pull/162/commits/b123d907c6eafc6260114a7ef3b15d10a7cbcc3e

The alternative would be a event system with a configuration. The sending of the mail could tried for x times until magento give up.