unwanted chunked delivery
hello,
we've a mailing-list with currently 81 recipients running with debian-dist mailman3 3.3.3-1.
every post to this list will be chunked into one delivery with 60 recipients and one delivery with 21 recipients.
we've searched a bit and found a config-option "max_recipients" for bulk-transfers, but we haven't set it and (as we understand the explaination for this option) then there should be no limit in one transfer to the MTA.
nevertheless, we've tried to set it to a high value, but even this doesn't change anything in behaviour.
any search for '60' within mailman3 gives no relevant results.
could someone tell us, where the limit of 60 comes from and how we could change it to unlimited?
thanks.
omf
On 1/7/22 11:04 AM, mm3-omf@sh.werbittewas.de wrote:
debian-dist mailman3 3.3.3-1.
every post to this list will be chunked into one delivery with 60 recipients and one delivery with 21 recipients.
we've searched a bit and found a config-option "max_recipients" for bulk-transfers, but we haven't set it and (as we understand the explaination for this option) then there should be no limit in one transfer to the MTA.
If you haven't set max_recipients, you get the default which is 500. To set it unlimited you set it to 0
nevertheless, we've tried to set it to a high value, but even this doesn't change anything in behaviour.
Right, because chunking isn't arbitrary. Chunking is done by recipient
domain. The addresses are placed in buckets by TLD. All .com goes in
one bucket; .net and .org in another; .edu, .us and .ca in a
third, and all the rest in a fourth.
Then the buckets are chunked with the maximum chunk determined by max_recipients.
In your case, 60 recipients are in one bucket and 21 in another.
The buckets are defined at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/mta/bulk.py#L29 and the work is done at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/mta/bulk.py#L56
My question is why is this important to you? See the FAQ article at https://wiki.list.org/x/4030582 (which is for Mailman 2.1 so it talks about SMTP_MAX_RCPTS which is what max_recipients used to be called) which suggests a much smaller number.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Am 07.01.22 um 21:33 schrieb Mark Sapiro:
nevertheless, we've tried to set it to a high value, but even this doesn't change anything in behaviour.
Right, because chunking isn't arbitrary. Chunking is done by recipient domain. The addresses are placed in
bucketsby TLD. All.comgoes in one bucket;.netand.orgin another;.edu,.usand.cain a third, and all the rest in a fourth.
thanks for this info.
My question is why is this important to you? See the FAQ article at
well, most of these 81 users are handled on our local system, but with different domains and TLDs (mainly 80% .de and 20% .org/.net). therefore we don't see any benefit in chunking here, especially in case 50% of the chunks are unused (.com,.edu/.us/.ca).
to simplify our logging-analysis in case of problems it seems beeter for us to have one entry for delivery to list-server and one entry for delivery from there.
https://wiki.list.org/x/4030582 (which is for Mailman 2.1 so it talks about SMTP_MAX_RCPTS which is what max_recipients used to be called) which suggests a much smaller number.
I understand, why chunking may have benefits perhaps in most situations, so it's set as default, but it would be great, to have the possibility to disable this without patching code, which might get overwritten with an update.
omf.
On 1/7/22 2:12 PM, mm3-omf@sh.werbittewas.de wrote:
I understand, why chunking may have benefits perhaps in most situations, so it's set as default, but it would be great, to have the possibility to disable this without patching code, which might get overwritten with an update.
You could submit an issue as a feature request at https://gitlab.com/mailman/mailman/-/issues, but I don't think we'd give it much priority. I think the trend these days is more towards enabling personalization and/or VERP which require one recipient per transaction.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Mark Sapiro -
mm3-omf＠sh.werbittewas.de