Hi,
the MM feature list says: "Direct SMTP delivery of messages, including integrated fast bulk mailing." i guess this is build into mailman to speed up mail delivery... but when mail is send out during approving (many) held back messages through the web admin interface, i wonder if it's still effective to use this bulk mailing technique? when all messages need improval before being send out, it's no use to have mailman try his best to deliver the mail as quickly as possible anyway... I don't know much about the way MM delivers mail, but some big annoyances i've had with using MM are that when approving several messages from the admin interface : (a) the cgi process(es) takes *too* long to finnish (causing timeouts sometimes) and (b) they cause a huge load on the system. Would it be possible to be able to choose for a "relaxed" way of delevering mail in certain situations? i'd rather have the messages being delivered with a small delay then MM trying hard to be as quick as possible with delivery...
hoping for at least one reaction to this email, :) Ricardo.
--
"RK" == Ricardo Kustner <ricardo@miss-janet.com> writes:
RK> I don't know much about the way MM delivers mail,
RK> but some big annoyances i've had with using MM are that when
RK> approving several messages from the admin interface : (a) the
RK> cgi process(es) takes *too* long to finnish (causing timeouts
RK> sometimes) and (b) they cause a huge load on the system.
RK> Would it be possible to be able to choose for a "relaxed" way
RK> of delevering mail in certain situations? i'd rather have the
RK> messages being delivered with a small delay then MM trying
RK> hard to be as quick as possible with delivery...
RK> hoping for at least one reaction to this email, :)
Here's one, hopefully the one you're looking for! :)
All this stuff has changed in the current codebase, available via CVS. The old bulkmailer stuff is gone and Mailman now has two ways to hand a message off to your MTA: either by calling sendmail (or a sendmail compatible program) via the command line, or talking asynchronously (no-DSN) via SMTP. All these means that the handoff of messages from Mailman to your MTA happens very quickly.
Dragon has mentioned that he has a robust bulk-mailer which may get ported to the new codebase and added back in. The neat thing is that with the current architecture, a site could choose any one of these delivery modules, as appropriate for their system (or easily implement their own).
-Barry
Hi,
On Sun, Dec 05, 1999 at 09:58:08PM -0500, Barry A. Warsaw wrote:
RK> Would it be possible to be able to choose for a "relaxed" way RK> of delevering mail in certain situations? i'd rather have the RK> messages being delivered with a small delay then MM trying RK> hard to be as quick as possible with delivery... RK> hoping for at least one reaction to this email, :)
Here's one, hopefully the one you're looking for! :)
yes it is... thanks! :)
All this stuff has changed in the current codebase, available via CVS. The old bulkmailer stuff is gone and Mailman now has two ways to hand a message off to your MTA: either by calling sendmail (or a sendmail compatible program) via the command line, or talking asynchronously (no-DSN) via SMTP. All these means that the handoff of messages from Mailman to your MTA happens very quickly. ah very nice ... i think i'm going to test out the cvs version on my pc at home... do all the python lists use this codebase too?
ported to the new codebase and added back in. The neat thing is that with the current architecture, a site could choose any one of these delivery modules, as appropriate for their system (or easily implement their own). ah even better !
btw i noticed some speed improvement when i switched from exim to postfix... I think i've tried out almost every possible MTA, but it seems postfix does it's best on a not-so-powerfull server with mailman.
Ricardo.
--
participants (3)
-
Barry A. Warsaw
-
Barry A. Warsaw
-
Ricardo Kustner