Hello, thanks for your replies.
The rationale of segmening big envelopes into smaller ones is to avoid both bounces and putting messages in the Junk folder. Imagine two email addresses, which have different preferences on what emails to accept. Let’s say the one destination address is a mailing list, where only some From:/Sender:/Resent-From:/Resent-To:/env.From addresses can post (the allowed address has to be in any of the five fields) and a normal user without such preferences. Accepting the mail to both recipients means, that the MLM has to bounce the message, or some human has to spend time with the spool of the MLM. The needed time for the latter is in practice indefinite, so not an option. Sending bounces means that the server can get blacklisted by some backscatters BL. Rejecting the message for both recipients is not an option, as the human has the right to receive it. Segmenting the message into two, does not have these problems. So on the first iteration at RCPT level the message is accepted only for the MLM and defered for the human and then rejected after DATA. On the second iteration the message is accepted for the remaining recipient after RCPT and after DATA. No bounces are sent and nobody is bothered checking the queue of messages for the MLM. Segmentation has the disadvantage of delayed mail delivery, but not doing segmentation also has disadvantages. In practice this does not have to be 50 segmented emails for a mail with 50 envelopes. If most recipients share the receiving preferences, all these recipients can be accepted it the same SMTP transaction. Regards Дилян On Mon, 2019-07-29 at 15:53 -0400, Wietse Venema wrote: > OP: > > Why doesn?t postfix handle the 4.5.3 status code in a special way? > > As long as per iteration the number of recipients > > is reduced, keep retrying without giving up. > > Because Postfix needs to be able to deliver email to many sites, > without allowing one receiver to get more Postfix resources > than other receivers. It is a basic security/robustness issue. > > Less diplomatical than Victor: ignoring $smtp_mx_session_limit > or $smtp_mx_address_limit, depending on receiver responses, would > be a stupdendously bad idea. > > Wietse