* Patrick Ben Koetter :
> From my daily work with mailman the following "modified in some way"-tasks
> come to my mind immediately:
>
> - apply client and content policy that differs from the port 25 anti-spam
> policy
> - add DKIM signatures because it is clear mailman messages are ORIGINATING
* Barry Warsaw :
> I am happy to announce the release of the third alpha version of Mailman
> 3, code named "Working Man".
Congratulations!
> Highlights in this release include the start of a REST admin server for
> integrating Mailman with external web sites, a combined bin/mailman
> uber-com
re, for example, a network outage and the MTA would queue the
contents of 10 timeslices until the network is restored, all that
refined flow control was for nothing.
Honestly, I don't know what kind of "wacky" the remaining 20% of
mailman users could want, but I can think of some thi
rove the sorting
algorithm (all TLDs, don't return partial chunks) or make it
configurable to skip sorting altogether. Or at least that's what I
feel would be an improvement. Have it default to flat chunking. It
saves CPU time, I/O operations and gives the MTAs queue manager more
* Mark Sapiro <[EMAIL PROTECTED]> wrote:
> Stefan Förster wrote:
>> I don't think I'm qualified to discuss my concern (which involves VERP
>> delivery using a specific MTAs VERP implementation and a highly I/O
>> saturated mail server) on this list.
>
>
Hello there,
I don't really know how to start this topic, I'm fairly new to Mailman
and I don't speak anything but the most basic Python, but I am unsure
whether the function "def chunkify(recips, chunksize):" which is
defined in "Mailman/Handlers/SMTPDirect.py" might not have an adverse
effect on
