Re: Call for testing: 2.0.0 is close to the doors
[email protected] Thu, 2 Apr 2026 16:04:11 -0700
| Newsgroups | org.mlmmj.mlmmj |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------YzbgNAuR1fpu0UE2STMR0YM7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Thanks, I looked up the postfix docs, and will try this! Philip On 4/2/2026 1:02 PM, Baptiste Daroussin wrote: > I don t think such configuration belongs to mlmmj should be imho on > the MTA side, for example on postfix, I think something this should > cover your need > > default_destination_rate_delay = 5s can ve configured more fine grained > > Bapt > > > Le 2 avril 2026 21:12:32 GMT+02:00, [email protected] a écrit : > > This may have already appeared in a recent rev... but I have a > question/request: > > Is there a tunable (or can someone create one) that would set a > throttle on the # of emails sent within a time period (i.e. no > more than 10 emails sent per minute)? > > Using mlmmj, I continue to see (in my server logs) that the big > email service vendors (gmail, microsoft, comcast, etc.) will > deliver a handful of emails sent their way, but then balk at some > point, and send a response about "deferring" delivery of the rest > of the emails sent to them; which usually means they don't send > the rest at all. This happens even with relatively small email > lists (< 150 emails). With a very limited list (<12 emails) all > emails are delivered. > > The reason I think a "throttle" tunable would be useful, is > because on the same server, I have separate internal processes > that periodically send email notifications effectively to the same > emails, based on some user-profile condition. The code builds a > custom email for each user-profile, and then sends out that email > and moves to the next profile. > > I have an adjustable throttle for that process, and have > experimented with time intervals. Slowing down the deliveries does > in fact get all the emails delivered. Of course this means it > slows down the time it takes to deliver all the emails, but under > most conditions, at least for me, that's not an issue. > > Would it be possible to add a time "throttle" tunable that would > enable some control over how fast the server sends out the emails? > > Very respectfully, > > Philip > > > > On 3/29/2026 1:26 AM, Baptiste Daroussin wrote: >> Hello Everyone >> >> In 2022, I took over the maintenance of mlmmj which I am using for the FreeBSD mailing lists and more. >> >> I am close to have delivered all the features I intended to add as such I would like to stamp it with naming the next release: 2.0.0! >> >> Here is what happened since 1.3.0 >> >> - Code cleanup and modernization >> - Addition of a test suite which lead to plenty of fixes >> - Fix many of RFC compliances issues >> - Improved bounce email by adding the messageid to it >> - Finish the old non finished "subrelease" feature >> - Add autoscribe feature >> >> The new things from 1.8.0 to 2.0.0 are: >> - new build system >> - by default respect RFC 2919/2369 List-* and Precedence headers generated by default (can be disabled via nolistheaders) >> - Subscription follow reply-to for confirmations >> - X-Forwarded-To (Gmail forwarding) (xforwardedto tunables) (incompatible with VERP) >> - X-Signed-Recipient (DARA/ARC) (data tunable). (Incompatible with VERP) >> - A bit of hardening >> - some portability fixes >> - archive partionning option (archive/YYYY/MM) with automatic migration (that's per request of Gentoo people) >> >> Please test and send feedbacks! >> >> note: autotools are not needed anymore but the build workflow remain the same: >> >> ./configure >> make >> make check >> >> Best regards, >> Bapt >> >> >> > --------------YzbgNAuR1fpu0UE2STMR0YM7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <font size="4" face="Helvetica, Arial, sans-serif">Thanks, I looked up the postfix docs, and will try this!<br> <br> Philip<br> <br> <br> </font><br> <div class="moz-cite-prefix">On 4/2/2026 1:02 PM, Baptiste Daroussin wrote:<br> </div> <blockquote type="cite" cite="mid:[email protected]"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <div dir="auto">I don t think such configuration belongs to mlmmj should be imho on the MTA side, for example on postfix, I think something this should cover your need<br> <br> default_destination_rate_delay = 5s can ve configured more fine grained<br> <br> Bapt<br> </div> <br> <br> <div class="gmail_quote"> <div dir="auto">Le 2 avril 2026 21:12:32 GMT+02:00, <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> a écrit :</div> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <font size="4" face="Helvetica, Arial, sans-serif">This may have already appeared in a recent rev... but I have a question/request:<br> <br> Is there a tunable (or can someone create one) that would set a throttle on the # of emails sent within a time period (i.e. no more than 10 emails sent per minute)?<br> <br> Using mlmmj, I continue to see (in my server logs) that the big email service vendors (gmail, microsoft, comcast, etc.) will deliver a handful of emails sent their way, but then balk at some point, and send a response about "deferring" delivery of the rest of the emails sent to them; which usually means they don't send the rest at all. This happens even with relatively small email lists (< 150 emails). With a very limited list (<12 emails) all emails are delivered.<br> <br> The reason I think a "throttle" tunable would be useful, is because on the same server, I have separate internal processes that periodically send email notifications effectively to the same emails, based on some user-profile condition. The code builds a custom email for each user-profile, and then sends out that email and moves to the next profile. <br> <br> I have an adjustable throttle for that process, and have experimented with time intervals. Slowing down the deliveries does in fact get all the emails delivered. Of course this means it slows down the time it takes to deliver all the emails, but under most conditions, at least for me, that's not an issue.<br> <br> Would it be possible to add a time "throttle" tunable that would enable some control over how fast the server sends out the emails?<br> <br> Very respectfully,<br> <br> Philip<br> <br> <br> </font><br> <div class="moz-cite-prefix">On 3/29/2026 1:26 AM, Baptiste Daroussin wrote:<br> </div> <blockquote type="cite" cite="mid:[email protected]"> <pre wrap="" class="moz-quote-pre">Hello Everyone In 2022, I took over the maintenance of mlmmj which I am using for the FreeBSD mailing lists and more. I am close to have delivered all the features I intended to add as such I would like to stamp it with naming the next release: 2.0.0! Here is what happened since 1.3.0 - Code cleanup and modernization - Addition of a test suite which lead to plenty of fixes - Fix many of RFC compliances issues - Improved bounce email by adding the messageid to it - Finish the old non finished "subrelease" feature - Add autoscribe feature The new things from 1.8.0 to 2.0.0 are: - new build system - by default respect RFC 2919/2369 List-* and Precedence headers generated by default (can be disabled via nolistheaders) - Subscription follow reply-to for confirmations - X-Forwarded-To (Gmail forwarding) (xforwardedto tunables) (incompatible with VERP) - X-Signed-Recipient (DARA/ARC) (data tunable). (Incompatible with VERP) - A bit of hardening - some portability fixes - archive partionning option (archive/YYYY/MM) with automatic migration (that's per request of Gentoo people) Please test and send feedbacks! note: autotools are not needed anymore but the build workflow remain the same: ./configure make make check Best regards, Bapt </pre> </blockquote> <br> </blockquote> </div> </blockquote> <br> </body> </html> --------------YzbgNAuR1fpu0UE2STMR0YM7--