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. _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
