On Thu, 2003-10-30 at 00:08, J C Lawrence wrote:
> Hang-on. Apache isn't the target. Mailman's UI is a CGI app. As such
> it works with any web server that supports CGI-bin, which pretty much
> means any web server with no exceptions. That's a pretty large gain,
> especially in the novice admi
On Thu, 30 Oct 2003 09:15:35 -0500
Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Thu, 2003-10-30 at 00:08, J C Lawrence wrote:
>> Hang-on. Apache isn't the target. Mailman's UI is a CGI app. As
>> such it works with any web server that supports CGI-bin, which pretty
>> much means any web server
Ok, I'm beat up enough, so let me open things up to a hopefully more
productive thread. How can Mailman more efficiently hand off messages
to a local mail server for final delivery?
Some problems with the current approach include:
- The desire/requirement that Mailman chunk and sort recipients
On Thu, 30 Oct 2003 07:04:19 +0100
Brad Knowles <[EMAIL PROTECTED]> wrote:
> At 12:40 AM -0500 2003/10/30, J C Lawrence wrote:
>> I've already said my bits there and proposed what I see as the cheap,
>> easy, incremental improvement course: Twisted's NNTP supports for
>> storage, Message IDs for
On Oct 30, 2003, at 6:38 AM, J C Lawrence wrote:
Sure, but I suspect that plumbing Mailman out to http will be just a
proxy rule away from integrating with an existing web server. That's
not without its headaches too, but should be as widely supported.
Considerably more web servers support CGI-bi
At 9:53 AM -0500 2003/10/30, Barry Warsaw wrote:
I'm sure you guys can identify more issues . Look at the
complexity in SMTPDirect.py, and even there, we still have problems.
I'm not a programmer, so I can't really help you there. ;-(
So how do we design a system where we can push the compl
On Oct 30, 2003, at 7:48 AM, Brad Knowles wrote:
"Tuning Sendmail for Large Mailing Lists"
http://tinyurl.com/t09c
400K/day aggregate max
"Drinking from the Fire(walls) Hose:
http://tinyurl.com/t09k
380K/day aggregate max
(yawn. My
At 8:41 AM -0800 2003/10/30, Chuq Von Rospach wrote:
(yawn. My server's bored. snicker)
Understood, but the techniques they recommend are still valid.
but seriously, both of them are built around pre sendmail 8.12
environments.
True.
there's some interesting stuff there, but
> "claw" == J C Lawrence
> "Re: [Mailman-Developers] Requirements for a new archiver "
> Wed, 29 Oct 2003 21:22:32 -0500
claw> I may be unusual in this regard, but I generally consider
claw> list archives as one-way systems: messages go in and never
claw> come out.
Out of
On Thu, 30 Oct 2003 16:20:10 -0500
John A Martin <[EMAIL PROTECTED]> wrote:
> Out of idle curiosity, why doesn't 'write once read many' indicate a
> directory more than a database?
1) The filesystem is a database.
2) Unix filesystems have extremely limited meta-data.
3) A discussed format is p
On Tue, 2003-10-28 at 13:30, J C Lawrence wrote:
> Yup. Of course this heads directly into that beautiful debate of
> whether MLMs should rewrite Message IDs. Summarising briefly:
>
> If we rewrite all IDs we'll piss off the people who use ID to do dupe
> detection/deletion for courtesy cop
On Wed, 2003-10-29 at 13:30, J C Lawrence wrote:
> 2) Message IDs are not guaranteed globally unique, but the collision
> rate can be manageable/acceptable in a large number of deployment
> cases.
Ah, which reminds me, elaborating on my strawman, the answers to "when
should Mailman rewrite
On Thu, 30 Oct 2003 17:47:18 -0500
Barry Warsaw <[EMAIL PROTECTED]> wrote:
> In the spirit of RFC 2369 we define a new header called
> List-Message-ID, and as in that standard, this field MUST only be
> generated by a mailing list, not by end users. Nested lists SHOULD
> remove the parent's List
On Thu, 30 Oct 2003 17:51:27 -0500
Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Wed, 2003-10-29 at 13:30, J C Lawrence wrote:
>> 2) Message IDs are not guaranteed globally unique, but the collision
>> rate can be manageable/acceptable in a large number of deployment
>> cases.
> Ah, which reminds
On Thursday 30 October 2003 05:17, J C Lawrence wrote:
> > ...as well as implement a bulk mailer to eliminate the need for an
> > outgoing mail server.
>
> Eeeek! I trust this would be for immediate handoff to a "real" MTA
> versus handling final delivery directly? Quite the Pandora's box if
> n
On Fri, 31 Oct 2003 00:45:32 +0100
Simone Piunno <[EMAIL PROTECTED]> wrote:
> On Thursday 30 October 2003 05:17, J C Lawrence wrote:
>>> ...as well as implement a bulk mailer to eliminate the need for an
>>> outgoing mail server.
>> Eeeek! I trust this would be for immediate handoff to a "real
On Thu, 30 Oct 2003 18:20:56 +0100
Brad Knowles <[EMAIL PROTECTED]> wrote:
> At 8:41 AM -0800 2003/10/30, Chuq Von Rospach wrote:
> One of them is recipient sorting by average delivery time over the
> past week (probably want a decaying geometric mean), which would
> require tracking log data on a
On Thu, 30 Oct 2003 08:41:17 -0800
Chuq Von Rospach <[EMAIL PROTECTED]> wrote:
> On Oct 30, 2003, at 7:48 AM, Brad Knowles wrote:
> One big reason: increasing spam blocking (stupid or otherwise) of
> non-individually addressed email. The old list server setup of:
> to: subscribers of list <[EMAI
On Thu, 30 Oct 2003 09:53:19 -0500
Barry Warsaw <[EMAIL PROTECTED]> 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
>
19 matches
Mail list logo
