Hello, That is a very good question.
We currently have in the development backlog the plan to develop a SMTP test suite for outbound SMTP. This question is quitte touchy as: - We want a complete customisation of the return code of the various servers - We want to test the complete mechanism, including DNS resolution ande related errors. Currently we are looking for a way to have a Mock TCP server in a docker that we could rely on but we did not do much progress on this yet. Clearly, once this test suite is available, that will be our pleasure to test every signle corner case we can think of, yours included. Best regards, Benoit On 29/07/2019 16:41, Дилян Палаузов wrote: > Hello, > > 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. > > Sendmail and postfix send in this case “452 4.5.3”, exim sends just 452. > > What does Apache James send? I cannot find anything related in the source > code. > > How can Apache James be tweaked to retry immediately: > • Does Apache James 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 > Apache James 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 Apache James 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. > > Regards > Дилян > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
