Re: Efficient final message disposition (was Re: [Mailman-Developers] Requirements for a new archiver)
On Thu, 30 Oct 2003 09:53:19 -0500 Barry Warsaw <barry@python.org> wrote:
- The desire/requirement that Mailman chunk and sort recipients
This shouldn't be any more complex than domain sorting, and need not be perfect.
- The ability for Mailman to swamp the mail server or cause the mail server to consume all available cpu
Rate limiting.
- The fact that failures in upstream mail server are reported to Mailman as bounces instead of as error codes
I don't know that Mailman can do anything about this. We can't reliably distinguish between system errors and delivery failures for MTAs beyond Mailman's borders. There's a protocol hole here I don't know we can or should attempt to fix.
- Inefficiencies in VERP/personalization/mail-merge because of the lack of cooperation
Oh yeah.
- The need for Mailman to queue outgoing messages that aren't completely delivered
Queue runner could do with some more intelligence in that dept.
Mailman wants to simply hand that data off to some agent and forget about it. It wants to know that the agent will make best effort to mail merge and deliver. It wants to be informed of any final delivery failures. And that's it. Mailman doesn't want to chunkify recipients, and it doesn't want to sort them. It doesn't want to worry about a mail server effectively managing system resources. I'd rather not have to hand it a couple of meg of recipient or substitution data, but there seems to be no other way.
So what can we do here to improve matters?
Start yelling at DJB, Wietse, Phillip, and Eric about a standardised SMTP extension for VERP. With a little luck and minor work we can probably get some of the other commercial mail people involved as well.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
participants (1)
-
J C Lawrence