You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some mailer providers change the Message-Id when sending the email. The getMessageId() method from SentMessage always returns the final ID of the message - whether it's the original random ID generated by Symfony or a new one generated by the provider.
When sending via smtp, Sendermail discards the Message-ID generated by Symfony and sends one of its own. It also sends a slightly different X-MailerSend-MessageID header. It seems that if a message has two or more addressees, each one receives a copy with a different Message-ID but the same X-MailerSend-MessageID.
After sending, however, SentMessage->getMessageId() returns the id generated by symfony, which does not appear in the sent message in any form, nor in Sendermail's webhooks.
Symfony\Component\Mailer\Bridge\MailerSend\Transport\MailerSendSmtpTransport should pass its X-MailerSend-MessageID into the SentMessage.
How to reproduce
Set up a mailersend trial account, install symfony/mailer-send-mailer (7.3.x-dev@19c7b14 or later) send an email, examine the sent email's headers and the value of SentMessage->getMessageId
Possible Solution
When mailersend sends via smtp, the last line of the smtp dialog looks like
250 Message queued as 683f5db51040ad4bf570339c
That alphanumeric is the value Mailersend assigns to X-MailerSend-MessageID.
It will become the Message-Id of the SentMessage if line 160 of Symfony\Component\Mailer\Transport\Smtp\SmtpTransport is changed from '/250 Ok:? queued as (?P<id>[A-Z0-9]+)\r?$/mis',
to '/250 (Ok:?|Message) queued as (?P<id>[a-fA-Z0-9]+)\r?$/mis',
The text was updated successfully, but these errors were encountered:
ovgray
changed the title
[Mailer][Mailersend Mailer] Smtp - Message-ID changed and change id not returned by SentMessage->getMessageId()
[Mailer][Mailersend Mailer] Smtp - Changes Message-ID and changed id not returned by SentMessage->getMessageId()
Jun 4, 2025
I am closing this issue and the related pull request because having looked at 3 third-party transports now I have question about the relationship between the message-id initially created by mailer, why it would or would not be modified by SmtpTransport, and how all that relates to the message id that ESPs use in their webhooks. If I can create a coherent statement of my questions, I will post it as a fresh issue.
Uh oh!
There was an error while loading. Please reload this page.
Symfony version(s) affected
7.3 (probably all since 6.4)
Description
This is a bug report if the following from https://symfony.com/doc/current/mailer.html is a promise of behaviour:
When sending via smtp, Sendermail discards the Message-ID generated by Symfony and sends one of its own. It also sends a slightly different X-MailerSend-MessageID header. It seems that if a message has two or more addressees, each one receives a copy with a different Message-ID but the same X-MailerSend-MessageID.
After sending, however, SentMessage->getMessageId() returns the id generated by symfony, which does not appear in the sent message in any form, nor in Sendermail's webhooks.
Symfony\Component\Mailer\Bridge\MailerSend\Transport\MailerSendSmtpTransport should pass its X-MailerSend-MessageID into the SentMessage.
How to reproduce
Set up a mailersend trial account, install symfony/mailer-send-mailer (7.3.x-dev@19c7b14 or later) send an email, examine the sent email's headers and the value of SentMessage->getMessageId
Possible Solution
When mailersend sends via smtp, the last line of the smtp dialog looks like
250 Message queued as 683f5db51040ad4bf570339c
That alphanumeric is the value Mailersend assigns to X-MailerSend-MessageID.
It will become the Message-Id of the SentMessage if line 160 of Symfony\Component\Mailer\Transport\Smtp\SmtpTransport is changed from
'/250 Ok:? queued as (?P<id>[A-Z0-9]+)\r?$/mis',
to
'/250 (Ok:?|Message) queued as (?P<id>[a-fA-Z0-9]+)\r?$/mis',
The text was updated successfully, but these errors were encountered: