Re: Call for testing: 2.0.0 is close to the doors
[email protected] Thu, 2 Apr 2026 12:12:32 -0700
| Newsgroups | org.mlmmj.mlmmj |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------vKl6AIt2Lpt6pAT0RF9fMWYE
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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
>
>
>
--------------vKl6AIt2Lpt6pAT0RF9fMWYE
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">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>
</body>
</html>
--------------vKl6AIt2Lpt6pAT0RF9fMWYE--