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