imagine, a mail envolope contains many recipient,  The server accepts the first 
recipients and rejects the last
recipients, meaning “Too many recipients in this transaction”.

RFC 821 specifies the reply code 452 as “Insufficient storage”, which RFC 5821 
amends, by stating that 452 can mean also
too many recipients in this transaction.

RFC 3463 defines enhanced status code 4.5.3 stating “Too many recipients”.  RFC 
5248 attaches the ESC 4.5.3 to reply
code 451, stating that changing this binding requires a specification, and 
there is no such specificaton.  The latter
means, that 452 4.5.3 is not valid.  Postfix and sendmail send “452 4.5.3”, 
exim sends on this occasion 452 without ESC.

How can Haraka be tweaked to retry immediately:
• Does openSMTPD interpret 4.5.3 anyhow special?
• Does it handle 451 and 452 differently by default?
• If a site publishes many MX records pointing to the same IP address, will 
openSMTPD do a lot of tries (reducing the
amount of pending recipients in each iteration) in shortes time?
• If a site published one MX records pointing to many different IPv6 addresses, 
will openSMTPD do a lot of retries to
deliver the same message in shortest time?

I guess, that a site publishing many MX records pointing to many IP addresses 
is not an additional option to increase
the retry rate.

SpamAssassin recomends inserting fake MX records 
https://cwiki.apache.org/confluence/display/spamassassin/OtherTricks .
How do these impact the retry algorithm?


Reply via email to