At 12:56 PM +1100 11/17/00, Andrew McNamara wrote:

Okay - the closest I can come to this off the top of my head is to define "fallback_transport" to point to a "pipe" transport that called Mailman.

Mailman would then receive all unknown local destinations, and would have to recognise owner- and -request style addresses also. It would also need to return EX_NOUSER (exit 67). Not as pretty, but should work okay.

How about, as an alternative, adding an LDAP api to Mailman (or some other interface that could be attached to something like LDAP). that way, you could write a really simple thing like wrapper that could dynamically look up whether a list exists and then do something useful with it. So instead of trying to add this functionality to Mailman, you add an interface that allows a special tool to be written that adds taht functionality -- and allows for other things (one thing I *really* want is subscription validation for external uses, like authentification into my archives. this kills both birds with one stone and a couple of simple glue procs...

Which leads me to something I've talked to Barry about, which is an open source authentification system that everything can plug into, including Mailman. So we can finally stop rewriting user databases from scratch every time we write a tool, and can integrate everything into a single system for a site... But that's down the road -- but think in terms of whether a feature like this stands alone, or whether a generalization of it can be used to solve multiple options.....

-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)

The vet said it was behavioral, but I prefer to think of it as genetic. It cuts down on the liability -- Get Fuzzy