Repeated error caused by large attachment zie


The other sent me an email with a 30+ MB pdf file and it is causing endless re-try and errors… Anything I can do to cancel the re-try?

Sender email server: Outlook
Did sender get failed delivery notice: No
Did other receipient receive the email: Yes, other receipients who use Gmail/Outlook emails successfully receive the email

The actual error code(s) (or message(s)) for the rejections are not clear from your post, - however:

30+ MB, as you indicate, might be too much for the final destination’s server to handle.

If the final destination is rejecting the message delivery with a temporary error code (e.g. with a 4xx code), that would, in your explained example, be causing Cloudflare to reject the message delivery from Microsoft Office 365 / Outlook, with a temporary error code as well.

That would mean that Microsoft Office 365 / Outlook would continue to do the re-tries, until they give up, which depends on their (Microsoft Office 365 / Outlook’s) specific configuration regarding that.

If the rejection is due to the message being too large for the final destination, it would indicate that the final destination has a misconfigured mail server, that is temporarily rejecting for that, rather than permanently rejecting it (e.g. with a 5xx code), which would be much better, if they do actually not like the message size.

In order to “fix” that part, it would be the final destination’s operators that would need to change their configuration.

No, the only one that can control the sending interval, as well as managing things such as e.g. cancelling one or more messages from the message queue, would be the sender, in your explained situation, Microsoft Office 365 / Outlook.

If I am reading your image well, it seems like this has been going on for almost 96 hours (4 days)?

The most typical configuration for re-tries are to re-try until the message is 120 hours (5 days) old, and then give up, and return it to the sender.

1 Like

Thank you for your detailed response. Hope the re-try will stop in 1 day (seems only 1 day to go to reach 120 hr)

It’s too much even for Cloudflare Email Routing to handle:

Currently, Email Routing does not support messages bigger than 25 MiB
Limits · Cloudflare Email Routing docs

So Perhaps it’s not even getting to try to deliver it to the destination.

It looks like Outlook’s default is 25 MB as well, although it is customizable
https://www.microsoft.com/en-us/microsoft-365/blog/2015/04/15/office-365-now-supports-larger-email-messages-up-to-150-mb/
Interesting how much it’s trying to retry though…

Of the same size?

1 Like

Indeed, it is.

Mine was however meant more as a general speech, if there are three destinations over Email Routing (25 MB), and the three individual destinations have three different limits, the two could perhaps go through successfully, but the third become rejected - perhaps in an incorrect way (4xx), re. above.

Fastmail seems to be known in the email community for using 4xx rejections, when they should have used 5xx.

Microsoft seems to be known to be very persistent, in regards to their retries:

Microsoft is quite often messing up their DNS, sometimes done in ways that are causing the FcRDNS (PTRA) test to fail, due to NXDOMAIN. Other times, it is failing due to some transient DNS errors.

A 4xx rejection in a such situation (e.g. due to the transient DNS error) would typically cause others to back up for a little while before re-trying, however, Microsoft appears to be re-trying them immediately.

What would also be interesting here though:

Was those other recipients that successfully received the message, also routed through Cloudflare Email Routing?

Or was it a multi-recipient message, where some recipients were going directly (@outlook.com, @gmail.com, …), but others through the Cloudflare Email Routing domain?

The latter could be the explanation to such discrepancies.

1 Like

Will report back

Yes

Yes, this is the case

That is pretty much explaining the issue why some can receive it, and some can’t, as it would be the individual recipient’s mail provider, that would make the choice of size limitation, which can vary a lot from server to server:

For the example with @outlook.com, @gmail.com , and the Cloudflare Email Routing domain, it would technically be three different operators, and thereby, there could technically also be three completely different sets of rules in terms of size limitations.

According to above, you should likely expect 25 MB for @outlook.com (25 MB) , it seems like 50 MB (receiving) for @gmail.com, and 25 MB for the Cloudflare Email Routing.

Note: In my memory, @gmail.com used to have a 35 MB limitation in the past, but these days, the current documentation (although, it appears targetted specifically for Google Workspace customers) says that the sending limit is 25 MB, but receiving limit is 50 MB, - potentially adding yet another discrepancy.

Regardless which mail provider you use, or want to send to, - if you’re actually looking to share (very) large files, it could be better to store the file(s) somewhere else, and send a link to the recipient instead, to avoid running in to such issues or discrepancies going forward. :wink:

1 Like

The retry finally stopped! Thank YOU for your great insights

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.