Bug #90320
closed
Swift_RfcComplianceException for invalid email in MailMessage->setTo()
Added by Stephan Großberndt almost 5 years ago.
Updated almost 3 years ago.
Description
There is a bug in the swiftmailer implementation in TYPO3 9.5 and 8.7:
GeneralUtility::makeInstance(MailMessage::class)
->setFrom('foo@bar.org')
->setTo('foo@ba r.org')
->setSubject('subject)
->setBody('body')
->send();
throws a Swift_RfcComplianceException
Address in mailbox given [foo@ba r.org] does not comply with RFC 2822, 3.6.2.
Swift_RfcComplianceException thrown in file
/typo3_src-8.7.30/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Mime/Headers/MailboxHeader.php in line 345.
In method MailMessage::send() a Swift_RfcComplianceException would be caught by Mailer::send() and add it to the list of $failedRecipients but MailMessage::setTo() does not.
TYPO3 v10 no longer contains the swiftmailer implementation.
- Category set to Backend API
- Status changed from New to Needs Feedback
Hey Stephan,
I tried fixing this in v9, however this is really difficult to achieve, as we don't know which addresses would have been failed (you can add multiple ones with >addcc() as well). Any ideas?
Benni Mack wrote:
Hey Stephan,
I tried fixing this in v9, however this is really difficult to achieve, as we don't know which addresses would have been failed (you can add multiple ones with >addcc() as well). Any ideas?
Its unfortunate that an invalid email address for the sender will lead to a Swift_RfcComplianceException PHP exception but a failing recipient will not. Maybe the setters should at least show a Swift_RfcComplianceException will be thrown on invalid values. The install tool checks each address before setting it by testing GeneralUtility::validEmail($recipient). I was not aware this should be done before using the MailMessage component. Maybe we should update the docs with a notice to always check adresses for validity before sending: https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Mail/Index.html
Just by looking at the code the same issue will occur in v10+, here a RfcComplianceException will be thrown:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Mime/Address.php#L55
Stephan Großberndt wrote:
Benni Mack wrote:
Hey Stephan,
I tried fixing this in v9, however this is really difficult to achieve, as we don't know which addresses would have been failed (you can add multiple ones with >addcc() as well). Any ideas?
Its unfortunate that an invalid email address for the sender will lead to a Swift_RfcComplianceException PHP exception but a failing recipient will not. Maybe the setters should at least show a Swift_RfcComplianceException will be thrown on invalid values. The install tool checks each address before setting it by testing GeneralUtility::validEmail($recipient). I was not aware this should be done before using the MailMessage component. Maybe we should update the docs with a notice to always check adresses for validity before sending: https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Mail/Index.html
Just by looking at the code the same issue will occur in v10+, here a RfcComplianceException will be thrown:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Mime/Address.php#L55
So you're suggesting to check on each ->addCC, ->addBCC etc call for a valid recipient before sending out the email?
My suggestion is to:
- improve the PHPDoc of the
MailMessage methods to inform the devs an exception (RfcComplianceException in master/v10, Swift_RfcComplianceException in v9) will be thrown on passing invalid email addresses to these MailMessage methods (setFrom(), ...)
- improve the core docs at https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Mail/Index.html in order to teach devs using
MailMessage to always check the validity of email addresses before passing them to those MailMessage methods
- Status changed from Needs Feedback to Closed
Closing this issue now since TYPO3 v9 is EOL for community support and Symfony/Mailer solves this differently. If docs should be improved, a new issue should be opened in the docs repository.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by