[Mailman-Developers] some more futures on mailman...

[Sean Reifschneider]

On Thu, Sep 14, 2000 at 12:13:02PM -0700, Chuq Von Rospach wrote:
>Yah. That one gets really interesting, really fast. There are all 
>sorts of wrinkles here, because even with sendmail, you start having 
>to tweak all sorts of files and keep them in coordination, and that 

I think that's beyond the scope of Mailman...  Besides, if your MTA
doesn't do these things well, you haven't really lost anything, you're
just back where you are now (except maybe you want to upgrade to a bit
more modern of an MTA ;-).  I'm sure that other MTAs handle it well,
but I know that QMail does.

Basicly, e-mail for "list@lists.domain.com" on my box gets forwarded
the local user "mailman-lists.domain.com-list".  I have a "default"
processing program set up for the mailman user which strips out the
domain name and destination, and sends it to the correct program with
the correct arguments.  At the moment it simply ignores the domain
portion.

>ignores the database backend details within mailman -- and how do you 
>resolve issues where the vhosting fails (for instance, not all web 

Again, I think that's beyond the scope of what we expect Mailman to
handle.  Garbage in, garbage out...  If the web server doesn't pass
the URL to the CGI, or uses an unknown domain, I'd expect mailman
to treat it as if it does now -- listing all domains/lists for the
admin page, and none on the listinfo page if the "show only this domain"
option is set...

>If you are on such a host, how do you get to the right pages if they 
>overload on top of each other in the namespace? ugh.

Are you talking about if they're using name-based virtual hosting, or ???
If you are running Mailman under a broken web server, I wouldn't expect
Mailman to do anything meaningful.  ;-)  Crippling people who ARE using
functional web servers (I mean, Apache is well over half the "market",
right?) just because somone might have a broken server doesn't help
anyone...  I don't see my changes as HINDERING people who use broken
servers, they just couldn't do the extra domain-based functionality.
They'd probably HAVE to set it so that all domains lists were shown
on listinfo and the like.

>At some point, you almost have ot start running multiple instances of 

Why?  There's a difference between installing multiple binaries, and
having a single set of binaries being able to access multiple sets of
data.  The latter is not evil.  ;-)

>mailman. You take the basic problem of trying to have 
>"chuqui@plaidworks.com" and "chuqui@chuqui.com" going to different 
>people on the same machine -- and throw gasoline on the problem.

As I said, with QMail at least it's not really an issue.  The mail
goes to "mailman-plaidworks.com-chuqui" and "mailman-chuqui.com-chuqui",
which my delivery program would then be able to handle to the list
processing program with the arguments "plaidworks.com" and "chuqui".
In sendmail you'd have to do more work to set up the individual
accounts, but it shoudl be doable there as well:

chuqui@plaidworks.com: |/home/mailman/bin/whatever chuqui plaidworks.com

>Me -- I handle it by not allowing it. I *could* figure out a way, but 
>it just plain old isn't worth the hassle.

Maybe not to you, but IMHO there is good reason to have it in Mailman.
I don't run into it being a problem right now, but as I add more
domains it's likely to be.  As we're hosting the lists for free as
a community service, nobody is likely to complain, but it's still
worth doing IMHO.

>What we're talking about (and need) instead is a hierarchic 
>inheritance system. you send off a request for "the unsubscribe 
>message", and mailman goes off and finds it. Starting at the most 
>specific place in the hierarchy and working down to distribution 
>definitions, it returns the first one it finds.

Yeah, like a search path.  ;-)  Why are you mapping the concept
"searching a list of locations" onto the OOP domain?

>The hierarchy would look something like: 
>user->list->host->site->distribution. And the trick is to define each 
>object (like 'unsubscribe message') in terms of other objects, and 
>customize each object at whatever level in the hierarchy is 
>appropriate. That way, list-specific stuff lives iwth the list, not 
>the host. and the two can be changed independently, or list stuff can 
>override host stuff.

How are you defining the objects based on other objects?  Are you saying
that the host "unsub message" would be a concatenation of the
distribution and site messages?

>defining what objects you need and what the hierarchy is, and also 
>who the owner is -- because there are going to objects that CAN'T be 
>overridden higher in the hierarchy, or that an site-owner will want 
>to tie down and not let a host owner or list owner override.

Presumably, if you read a "list unsub message" it may search back up
the heirarchy searching for that message, but if you write it it would
write directly to the list context, not search upwards.

Sean
-- 
 [...] who asked "Why do we do it, this science?"  No one had an answer until
 I stood up and said "Isn't there money in a Nobel?"  -- Steve Martin
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python