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

Reply via email to