[Top] [All Lists]

Re: [ietf-smtp] SMTP Retrying/Sending Strategy on 452 / 4.5.3

2019-02-11 03:13:11
On 11/02/2019 08:15, Дилян Палаузов wrote:
Is the number 100 randomly choosen?

Yes, I believe so (just like maximum line lengths, etc). It's more a "physical limitation of the server" response than a policy limitation. (In my experience, policy limitations on numbers of recipients per message tend to return 5xx responses, rather than 4xx ones).

So, just like the 1024 character line limit is rarely required nowadays, also a 100 recipient/message limit is going to be rarely needed - servers can handle a lot more than that, and unnecessarily requiring a retry to deliver to more recipients is just adding server/client load for no benefit.

Are clients supposed to retry immediately after receiving 452 4.5.3?

No, they're just supposed to retry sometime later.

In fact, you're breaking a 'MUST' in RFC 5321, Paragraph if you do retry immediately - you "MUST delay retrying a particular destination after one attempt has failed". OK, it doesn't say you can't just delay for 0.5 seconds, but a delay of some sort is definitely indicated, and SHOULD be at least 30 minutes (although most will try sooner than that for the first retry)

Note that extended SMTP reply codes are an option, not a part of the SMTP standard itself. There is absolutely no requirement for the sender to read anything beyond the first '4' digit of the base response code.

What will happen, if a site has one (1) as a minimum total number of recipients 
that are buffered?

It could take a very long time (possibly never) for a message to a large number of recipients to be delivered.

The problem with all these discussions is that the receiver server has no idea how the sender server will react. Retry strategies are not mandated by the SMTP standard. All that is required is that after a 4xx response the sender SHOULD try again at some later time, and on a 5xx response the sender MUST NOT try the same message again. (RFC 5321,, first 2 paragraphs are the required ones ).

That is *ALL* that the receiver can rely on. That's why a lot of the onus on delivery is down to the receiver.

If the receiver wants users to receive messages in a timely fashion, they should not issue 4xx responses arbitrarily - if they CANNOT accept the message because the disk is full, that's fine, but if they can accept the message, they should do so - if they want the recipients to have a chance to get the message quickly.

If the sender gets a 4xx response (the digits after the first '4' may not be read, and extended reply codes may not be read at all), then it will retry at some point - the first retry will possibly be within 10 minutes, probably within an hour, almost definitely within a day. It MAY send a 'message delayed' message to the sender at some point, but it may not.

If a message is repeatedly 4xx'd then the retry time may increase on subsequent retries, so, if you only accept a single message, and 4xx all the others, and there are only 10 recipients, the recipients may well get the message at these times:

1. 10:00
2. 10:05
3. 10:10
4. 10:40
5. 11:40
6. 12:40
7. 16:40
8. 20:40
9. 00:40
10. 04:40

That would be perfectly acceptable by the SMTP standards. (If there were 100 recipients, it's probable that the last 80 or so would never receive the message, because it's timed out before being sent).

Any optional drafts/standards that are written won't magically affect how all mail servers work. Their developers have to weigh up the cost in time & complexity vs any benefits gained to implement any optional features (and then users have to decide it's worth their while to install the updated versions and learn about/enable/configure the new features)


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at
ietf-smtp mailing list