Thank you so much everyone ! Sorry I'm only answering now. I threw the email just before leaving and couldn't access my emails sooner.
I wasn't aware this was mentioned in the RFC already but now I've updated the code to follow this (100 recipients). I'm a big advocate of respecting the RFC and email is an area where you sometime have to make trade off to work with other non-respecting providers (like you mentioned with AWS that accepts only 50 for instance) so whenever there is a clear definition in the RFC, I like to follow it (I just need to know about it hehe) Thank you for your help here, and also for suggesting the appropriate code and enhanced code. This was almost correct on my end (the enhanced code was correct but I was sending 451). All of this is adjusted now. Thanks ! And have a nice day :) On Thu, Dec 5, 2024, at 06:09, Viktor Dukhovni via mailop wrote: > On Wed, Dec 04, 2024 at 08:01:34PM -0600, Grant Taylor via mailop wrote: > > > On 12/4/24 09:45, Viktor Dukhovni via mailop wrote: > > > No, not a "421", since that would normally also be a connection abort, > > > and none of the recipients would get the mail. > > > > What do you think about a 450 4.2.1? > > Well, the correct reply code is 452. The correct enhanced status code > is 4.5.3: > > > https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml > > > > Rather, the correct handling is to softfail the excess recipients and > > > accept the initial batch that came in under the count. > > > > Please clarify what you mean by "softfail" in this context. I've seen > > different things and would hate to assume incorrectly. > > A 4XX response, such as: 452 4.3.5 ... > > Now an MTA will typically impose a smaller limit (than 100) on the count > of *invalid* recipients before the connection is closed with 421 or 521. > > That is so long as the recipients are essentially all valid, it should > accept 100 + some tolerance for pipelining to have sent a bunch more, > before the first 452 was noted in response. Once enough of the > recipients are bad, abuse prevention kicks in and the RFC lower-bound > ceases to be the primary concern. > > -- > Viktor. > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
