8000 [Mailer] SMTP transport creates too many NOOP commands · Issue #35515 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[Mailer] SMTP transport creates too many NOOP commands #35515

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
micheh opened this issue Jan 29, 2020 · 2 comments
Closed

[Mailer] SMTP transport creates too many NOOP commands #35515

micheh opened this issue Jan 29, 2020 · 2 comments
Labels
Feature Mailer

Comments

@micheh
Copy link
Contributor
micheh commented Jan 29, 2020 •
edited
Loading

When using the SMTP transport for the Mailer component, it can be difficult to send many emails within the same SMTP session.

The problem is that the transport will ping the server (send a NOOP command) before every email:

symfony/src/Symfony/Component/Mailer/Transport/Smtp/SmtpTransport.php

Line 163 in 7ecb5aa

$this->ping();

This is fine if you send only a couple of emails, but may lead to problems when sending more than 10 emails, as SMTP servers usually will drop the connection with too many nonmail commands (like NOOP).

A potential workaround is to call setRestartThreshold in order to restart the connection after a specified number of mails was sent (e.g. 10). But maybe it is a better idea to not ping the server before every email?
@Nyholm
Copy link
Member
Nyholm commented Jan 29, 2020

Thank you. I think it makes sense to ping it once per ever x seconds. Ie, if we have a long running process that sends one email every hour, we sure want to ping with every email.

But if we send 100 mails in 10 seconds, then yes, one ping is enough.

Could one save a local cache when we last pinged? And if we pinged the last 10(?) seconds, then we just ignore it. Is that a good solution?

@Nyholm Nyholm added the Mailer label Jan 29, 2020
@xabbuh xabbuh added the Feature label Jan 31, 2020
@micheh
Copy link
Contributor Author
micheh commented Jan 31, 2020

Yes, we could save the time when the last email was sent with the transport and then compare this with the current time before a new email is sent. Only if the difference is above a threshold, the server will be pinged.

However, I think 10 seconds is still way too low. The default timeout is 5 minutes according to RFC5321. With a threshold of only 10 seconds, it is much more likely that the connection will still be dropped due to too many NOOP commands than an actual timeout.

@xabbuh This is a bug, not a feature.

@micheh micheh mentioned this issue Feb 7, 2020
Merged
@fabpot fabpot closed this as completed Feb 7, 2020
fabpot added a commit that referenced this issue Feb 7, 2020
@fabpot
bug #35633 [Mailer] Do not ping the SMTP server before sending every …
cb42480 
…message (micheh)

This PR was squashed before being merged into the 4.4 branch (closes #35633).

Discussion
----------

[Mailer] Do not ping the SMTP server before sending every message

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #35515
| License       | MIT

This pull request changes the SMTP transport to only ping the server if the last message was sent more than a specified number of seconds ago (instead of pinging the server before every message). By default, it will ping the server if 100 or more seconds since the last message have passed.

This should make sending emails with the SMTP transport more robust with many emails, as SMTP servers will often drop the connection if too many non-mail commands are sent (like pinging the server with NOOP commands).

Commits
-------

2817810 [Mailer] Do not ping the SMTP server before sending every message
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Feature Mailer
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@fabpot @Nyholm @micheh @xabbuh
0