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
>
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 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 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 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 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 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 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 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 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
> "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
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
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 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 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
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
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 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
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
19 matches
Mail list logo
