[Mailman-Developers] MM Bouncer

[Peter C. Norton]

On Thu, Dec 06, 2001 at 11:48:50AM -0500, Jay R. Ashworth wrote:
> > > With VERP, I have to send it 100 times.
> > 
> > Unless the MTA does the VERP for you,
> 
> Well, see, here's the thing.  That *still* doesn't unload the *wire*,
> just the MLM.

It also unloads the disk.  The wire is rarely where you need to save time.
I've seen a single mailhost with over a million messages queued empty out
overnight over a t1.  The biggest delays had nothing to do with mail traffic
over the wire.

> > When you start looking beyond 'just' VERP to what you can do to improve mail
> > lsits for the end user, especially the less technical ones, it starts being
> > a lot more interesting. And once you start adding in this functionality, you
> > can bring along VERP basically for free, whether or not you use a
> > VERP-capable MTA. 
> 
> At the expense of loading the wire, the MTA, *and* the MLM.
> 
> How big are your lists, Chuq?  :-)

Again, I don't think the wire is usually an issue.  The MTA could be
isolated to a special output channel that is just for "more-then-verp"
processes, so the MTA in general wouldn't be loaded, just the M-T-V process
and pipeline.

So, to speculate, a sensible MTA puts metadata in a seperate file.  To do
M-T-V you'd only have to can a message once in the queue, and if the M-T-V
flag is set then scan the file for replacement strings (I think it'd be
appropriate to have a flag, or a seperate process since mangling content in
the message is a bad thing to do most of the time).

One of the inputs for the M-T-V message->queue program should be a list of
replacement strings, with some specially reserved strings (like for VERP).

The M-T-V inputter should then record in the metadata the offset of each
replacement, and the string or command that would replace it.  This is
sounding more and more like a mass-mailing program, eh?  So each recipient,
instead of being an rfc822/2822 address would be a delimited string with an
822 address, and replacement string 1, 2, 3, etc...  and in the body of the
message would be a special character (say %1%, %2%, etc) that would be
subjected to positional replacement.

The re-writing would be done on the way out to the remote host, and it would
be pretty cheap to implement at this phase.  

Is this about the right idea?  

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.