Hello; Having worked in the meantime on the aforementioned test suite, I'm now able to better understand your question, and also precisely answer it:
On a RemoteDelivery retry James is trying all the MXs mentionned in the DNS records, ordered by priority until one matches. The "fake record" approach should have no negative effects, maybe some info logs might show off. Best regards, Benoit On 30/07/2019 01:16, Дилян Палаузов wrote: > Hello Benoit, > > I do not ask for a behavior that is verifiable by running tests, I ask what > is the default implementation. I mean, > documenting the default behaviour can certainly be performed without having > test coverage. > > SpamAssassin recomends inserting fake (lowest and highest) MX records > https://cwiki.apache.org/confluence/display/spamassassin/OtherTricks to > reduce Spam. E.g. MX aegee.org resolves to 90 > mxf-2.aegee.org. / 10 mail.aegee.org. / 1 mxf-1.aegee.org. and on > mxf-1,2.aegee.org there is no SMTP server. > > What is the impact of fake records on the retry strategy? > > Regards > Dilyan > > On Mon, 2019-07-29 at 17:06 +0200, Tellier Benoit wrote: >> 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 and >> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
