[Mailer] Expected response code "250" but got code "451"

[FrancisMawn]

Symfony version(s) affected

6.0.3

Description

We've upgraded our application to Laravel 9 last week and noticed a large amount of failed jobs appearing as soon as we deployed the build in production.

Those errors were all email related with the following error message:
Expected response code "250" but got code "451", with message "451 4.4.2 Timeout waiting for data from client.".

We've reverted back to the previous build (which was using SwiftMailer) and the errors stopped. To clarify, we've been running the application for a few weeks and never had that error before.

How to reproduce

The only way I was able to reproduce the error is by spamming the notifications to the point were we would eventually start getting the failed jobs with the exception again.

The error seems to occur when there's a fairly large amount of jobs being dispatched at the same time.

Possible Solution

No response

Additional Context

The notifications are dispatched to a third party server provider (which to my understanding is running on AWS).

I've seen an issue posted a few years ago which seem to be describing the exact same issue.

[FrancisMawn]

We got a response back from our email supplier and their explanation is that the AWS service will close any connections that are idle for more than 10 seconds.

Reference from AWS:
A "Timeout waiting for data from client" response means too much time elapsed between requests, so the SMTP server closed the connection. So once the connection with the Amazon SES SMTP server is established and your application does not send data within 10 seconds, the connection automatically closes after about 10 seconds of inactivity. The 10 seconds timeout value is a hard limit and a default value that cannot be changed..

So according to them, it's one of the following:
1- The connection to the server is opened and takes more than 10 seconds to send the content of the email.
2- The connections are re-used and not properly closed.
3- Attempt to "pool/reuse" SMTP server connections without proper mechanism to keep the connection alive between requests.

[dmaicher]

Maybe you need to experiment with the ping threshold configuration of the SmtpTransport.

[FrancisMawn]

@dmaicher Thanks for your response. This is what we ended up doing.

So for those of you who would come across the same issue:
Adding a ping_threshold of 10 in the mail config for the smtp driver solved the issue.

[HamzaSalih98]

This error message indicates that the mail server was expecting a response code of 250 from the client, but instead received a response code of 451 with the message "Timeout waiting for data from client." This means that the client took too long to send data to the server and the server timed out waiting for the data.

There could be several reasons for this issue, including network connectivity problems, server overload, or a malfunctioning client. To troubleshoot this issue, you can try the following steps:

Check the network connectivity between the client and server to ensure that there are no network issues causing the timeout.

Verify that the server is not overloaded with requests and that there is enough processing power and memory available to handle incoming requests.

Check the client configuration to ensure that it is sending data correctly and is not malfunctioning in any way.

If the issue persists, you may want to contact your email service provider for further assistance in resolving the problem.

[Y003]

We got a response back from our email supplier and their explanation is that the AWS service will close any connections that are idle for more than 10 seconds.

Reference from AWS: A "Timeout waiting for data from client" response means too much time elapsed between requests, so the SMTP server closed the connection. So once the connection with the Amazon SES SMTP server is established and your application does not send data within 10 seconds, the connection automatically closes after about 10 seconds of inactivity. The 10 seconds timeout value is a hard limit and a default value that cannot be changed..

So according to them, it's one of the following: 1- The connection to the server is opened and takes more than 10 seconds to send the content of the email. 2- The connections are re-used and not properly closed. 3- Attempt to "pool/reuse" SMTP server connections without proper mechanism to keep the connection alive between requests.

Thanks for the information, it really put some light on as to what caused the problem there. Thanks again!!

[ThomCM]

If the issue persists, you may want to contact your email service provider for further assistance in resolving the problem.

Thanks ChatGPT

[jackbaron]

@dmaicher Thanks for your response. This is what we ended up doing.

So for those of you who would come across the same issue: Adding a ping_threshold of 10 in the mail config for the smtp driver solved the issue.

It not working for me

[amanpatel123]

I get the same issue but ping_threshold does not work for me

[ThomCM]

@amanpatel123 @jackbaron it might be related to the attachments you're adding to the email being too large. This was the issue in my case.

// Check if the file size is less than 2MB (2 * 1024 * 1024 bytes)
$fileSize = Storage::size($this->dataExport->path);
$fileTooLarge = $fileSize >= 2 * 1024 * 1024;

$mailMessage = (new MailMessage)
     ->subject($this->dataExport->type->value . ' Export Complete (#' . $this->dataExport->id . ')')
     ->markdown('mail.data-export-complete', [
                'dataExport' => $this->dataExport,
                'fileTooLarge' => $fileTooLarge
      ]);

if (!$fileTooLarge) {
            $mailMessage->attach(
                Storage::temporaryUrl($this->dataExport->path, now()->addMinutes(60)),
                [
                    'as' => $this->dataExport->name,
                    'mime' => 'text/csv',
                ]
            );
}

[wouterj]

Please use one of the community support channels (https://symfony.com/support) to get help. We use the issue tracker solely for reporting/discussing bugs and new features.