On Oct 11, 2004, at 1:31 AM, Joe Rhett wrote:

Note that you may want to run bin/fix_url.py to change the domain of an existing list. fix_url.py must be processed by the withlist script, like so: bin/wishlist -l -r bin/fix_url.py <listname>

This sounds more clear to me.

Also, we might want to put this somewhere in the online help for the list admin pages, if it's not already there. I've had a few list admins get confused because there's no setting for it, just a setting for the email domain. I'd suggest that we add a note along these lines to the help for host_name. (eg: "Changing the domain for the web interface must be done from the command line by a site administrator.
See the INSTALL file for more details on how to do this.")

Joe Rhett wrote:

On this subject, why does creating a list with the host name set the web interface? In no circumstance that I have ever seen are they the same, except perhaps (in theory) for some hobbyist with a single computer?

$ newlist im@thejones.com

Sets the web interface to 'thejones.com' as well as the mail domain. This doesn't make a lot of sense except in the hobbyist environment. I may be off my rocker, but shouldn't this syntax set the mail domain and force you to change the web URL manually?

Well, the help for newlist (bin/newlist --help) is pretty clear that the notation name@domain is not the e-mail address of the list but just a way of specifying the web domain.

<quote> You can specify the domain to create your new list in by spelling the listname like so:

mylist@www.mydom.ain

where `www.mydom.ain' should be the base hostname for the URL to this virtual hosts's lists. </quote>

Still, I think you have a point. Mailman/Cgi/create.py checks in the case where VIRTUAL_HOST_OVERVIEW is on to see if the hostname is in VIRTUAL_HOSTS.

if mm_cfg.VIRTUAL_HOST_OVERVIEW and \
       not mm_cfg.VIRTUAL_HOSTS.has_key(hostname):
    safehostname = Utils.websafe(hostname)
    request_creation(doc, cgidata,
                     _('Unknown virtual host: %(safehostname)s'))
    return

Perhaps bin/newlist should do something similar.

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Joe Rhett wrote:

...

On this subject, why does creating a list with the host name set the web interface? In no circumstance that I have ever seen are they the same, ...

On Mon, Oct 11, 2004 at 11:47:37AM -0700, Mark Sapiro wrote:

Well, the help for newlist (bin/newlist --help) is pretty clear that the notation name@domain is not the e-mail address of the list but just a way of specifying the web domain.

Right, but it still seems counter-intuitive to me.

1. name@domain is the format of an e-mail address, not a web address

2. How often do you change the web url for list management?

3. How often does a given list have a different identity?

3:2 is more than 100:1 in every list environment I've ever seen. topped with the confused syntax presented in #1, I guess I am arguing that we change the behavior.

-- Joe Rhett Senior Geek Meer.net

Hmm I guess I still don't get why "name@domain" is confusing, because that -is- the posting address of the list! If you want to add another field for domain, that's fine; but I think the current behaviour makes sense.

Also, as I stated before, the web-based create should take the hostname used as the domain name. It currently forces one domain.

Bob

---------- Original Message ----------- From: Terri Oda <terri@zone12.com> To: Joe Rhett <jrhett@meer.net> Cc: mailman-developers@python.org Sent: Sun, 17 Oct 2004 19:02:44 -0400 Subject: Re: [Mailman-Developers] on the subject of fix_url, list creation with @ is non-intuitive..

On Oct 11, 2004, at 11:10 PM, Joe Rhett wrote:

...

On Mon, Oct 11, 2004 at 11:47:37AM -0700, Mark Sapiro wrote:

...

Well, the help for newlist (bin/newlist --help) is pretty clear that the notation name@domain is not the e-mail address of the list but just a way of specifying the web domain.

Right, but it still seems counter-intuitive to me.

I'm with Joe on this one -- just because it's a documented oddity doesn't make it the right way to do things.

Is there any particular reason we couldn't change the newlist script to accept "name domain" instead of "name@domain" ? It's just that much less confusing if we don't have this thing that looks like an email address but isn't. I can't believe anyone's that attached to the confusing syntax, and the increased usability seems worth the small patch this'll take.

Terri

---

Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com ------- End of Original Message -------

Hi Terri,

If your list machine isn't the same box as the webserver machine, then the web-based create isn't going to work. :-) I still think it makes sense.

Bob

Terri Oda wrote:

On Oct 17, 2004, at 8:43 PM, Bob Puff wrote:

...

Hmm I guess I still don't get why "name@domain" is confusing, because that -is- the posting address of the list! If you want to add another field for domain, that's fine; but I think the current behaviour makes sense.

Is it always the posting address, though? If you create a list:

mylist@www.example.com

isn't it possible that www.example.com is just a webserver and the mail is actually handled by some other domain (eg: lists.example.com) which may not be the same machine?

---

Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com

Right. But when would you use a www.domain? I never use www. Do people name their box www? I usually name the host something else. I think most people are smart enough to figure out that list_name@domain is not list_name@www.domain. You face the exact same problem of people doing the same things with two different parameters; i.e., bin/create list_name www.domain etc...

Whatever, its not a big deal, as long as the create script still works with the old syntax (which was my original point).

Bob

Terri Oda wrote:

On Oct 18, 2004, at 10:15 AM, Bob Puff@NLE wrote:

...

If your list machine isn't the same box as the webserver machine, then the web-based create isn't going to work. :-) I still think it makes sense.

Good point -- I'd forgotten we were still talking about web based creation. I was making man pages for the stuff in bin/ earlier this month, and the name@www.domain syntax is the same even when you're working from the shell, and that's where I don't think it necessarily makes sense.

Terri

---

Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com

On Mon, Oct 18, 2004 at 02:49:44PM -0400, Bob Puff@NLE wrote:

Right. But when would you use a www.domain? I never use www. Do people name their box www? I usually name the host something else. I think most people are smart enough to figure out that list_name@domain is not list_name@www.domain. You face the exact same problem of people doing the same things with two different parameters; i.e., bin/create list_name www.domain etc...

I think you are completely missing the point. In this case list@domain isn't list@domain at all. It's actually http://domain/mailman/listinfo/listname

Is that obvious? Not to me. Let's use something that appears to be an e-mail address as an obscure shortcut for a long web URL?

If it contains at '@' sign, it should refer to an e-mail address. If it contains 'http:' sign, it should refer to a web address. (rule #2 obviously overrides rule#1 when the URL contains an '@' ..)

Create should allow a second parameter to define the web url. But the '@' syntax really should refer to the mail domain.

-- Joe Rhett Senior Geek Meer.net

On Mon, Oct 18, 2004 at 10:15:56AM -0400, Bob Puff@NLE wrote:

If your list machine isn't the same box as the webserver machine, then the web-based create isn't going to work. :-) I still think it makes sense.

I'm not even dealing with the web-based create, I'm dealing with the command line. "list@domain" is clearly an e-mail address to any naked eye. However, this sets up list with a webserver @ domain, which is completely counter-intuitive.

-- Joe Rhett Senior Geek Meer.net

On Oct 24, 2004, at 10:19 PM, Barry Warsaw wrote:

I think you'd have to change this in a backward compatible way. A counter proposal would be to add name:domain (simply change the '@' to a ':') so it doesn't look like an email address. Continue to support the original argument syntax for backward compatibility, but change the documentation to favor the name:domain syntax.

I was thinking of doing the same thing but with a space instead of a :. I can't think of any reason not to keep the backwards compatibility as long as we don't leave the confusing stuff in the documentation.

If I didn't feel guilty using my laptop while proctoring my students' exam, I'd write the patch tomorrow while I'm stuck sitting in a quiet room. I might do it later in the evening, though, if no one else gets to it first.

Terri

--On Monday, October 25, 2004 4:44 pm +0900 Tokio Kikuchi <tkikuchi@is.kochi-u.ac.jp> wrote:

Hi,

Terri Oda wrote:

...

On Oct 24, 2004, at 10:19 PM, Barry Warsaw wrote:

...

I think you'd have to change this in a backward compatible way. A counter proposal would be to add name:domain (simply change the '@' to a ':') so it doesn't look like an email address. Continue to support the original argument syntax for backward compatibility, but change the documentation to favor the name:domain syntax.

I was thinking of doing the same thing but with a space instead of a :. I can't think of any reason not to keep the backwards compatibility as long as we don't leave the confusing stuff in the documentation.

Wouldn't it be better to introduce '--urlhost=' option and keep '@' for backward compatibility?

$ bin/newlist --urlhost=www.dom.ain listname or $ bin/newlist listname@www.dom.ain

No, because there are many types of URL (including mailto:iane@example.com email address specifications), so URL is not specific enough. Better would be --webhost

...

If I didn't feel guilty using my laptop while proctoring my students' exam, I'd write the patch tomorrow while I'm stuck sitting in a quiet room. I might do it later in the evening, though, if no one else gets to it first.

We need no hurry for release of 2.1.6 is not yet scheduled. ;-)

-- Ian Eiloart Servers Team Sussex University ITS

On Mon, 2004-10-25 at 03:44, Tokio Kikuchi wrote:

Wouldn't it be better to introduce '--urlhost=' option and keep '@' for backward compatibility?

$ bin/newlist --urlhost=www.dom.ain listname or $ bin/newlist listname@www.dom.ain

That's a good idea too. -Barry

On Mon, Oct 25, 2004 at 04:44:35PM +0900, Tokio Kikuchi wrote:

Wouldn't it be better to introduce '--urlhost=' option and keep '@' for backward compatibility?

$ bin/newlist --urlhost=www.dom.ain listname or $ bin/newlist listname@www.dom.ain

I agree with the logic, but I'd like a method to create listname@domain -without- altering the urlhost.

$ bin/newlist listname@mailhost
..seems intuitive but breaks compatibility

$ bin/newlist listname --mailaddr=listname@mailhost
..would suit my needs as long as urlhost was left alone

-- Joe Rhett Senior Geek Meer.net

On Tue, Oct 26, 2004 at 06:09:25PM -0700, Mark Sapiro wrote:

You already have the ability to set host_name (which is the e-mail domain) on the lists General Options page or with bin/config_list. Granted, it's not as convenient as being able to set it to other than its default with bin/newlist, but I think most people need to fine tune a list after creation anyway.

Most _people_ but not most sysadmins. This isn't my list. I want to set up the required settings for the list to function from the command line.

It's not like the setting is easy to find or understand for joe user. It's our biggest FAQ.

-- Joe Rhett Senior Geek Meer.net

On Wed, Oct 27, 2004 at 12:14:47AM -0400, Terri Oda wrote:

...

Most _people_ but not most sysadmins. This isn't my list. I want to set up the required settings for the list to function from the command line.

When I set up a list as a sysadmin, even for someone else, I invariably log in to the web interface to make sure it works. :)

Agreed, but fairly non-trivial to automate ;-0 Thus, command line...

...

It's not like the setting is easy to find or understand for joe user.
It's our biggest FAQ.

Interesting...

Do you happen to know where users look for this setting? If most people are looking in the same (wrong) place, then maybe it'd make sense to move the setting there.

"everywhere" according to them ;-)

It is probably a labeling thing more than a placement issue. Anyway, the goal is to have the script set up the mailing list in a working manner automatically. If they break it, they break it. But setting up the list in a broken manner and requiring the user to fix it is less useful.

-- Joe Rhett Senior Geek Meer.net

...

Most _people_ but not most sysadmins. This isn't my list. I want to set up the required settings for the list to function from the command line. .. Agreed, but fairly non-trivial to automate ;-0 Thus, command line...

Is I indicated in a previous post, bin/config_list can change it. It should be fairly simple to script writing "host_name = 'something'" to a file and then doing bin/config_list -i that_file listname.

It's also simple to run fix_url in a similar manner. So why is the url setting provided with newlist?

From our experience, most lists need the list mailaddr changed. Very very few need the urlhost changed. So I am asking why newlist doesn't do both.

I am curious. I'm not questioning your need, I'm just wondering why you have a need to create a list in a particular web domain with an email host different from the one set for that domain in VIRTUAL_HOSTS.

I think you completely misunderstand. I don't want to change the web domain -- that is the problem! The list server has only one name, ever. There are no virtual hosts involved. There are no web domains.

The goal is to allow people to have their lists inside their own domain, without having to find the value and fix it in their web admin.

Thus, lists.meer.net (the only name, no virtual hosts) hosts lists known as mylist@mydomain.com, hislist@hisdomain.net, herlist@herdomain.net, etc.

The admin interface for the domain will always be http://lists.meer.net/... It's the mailaddr for the domain which is almost always changed.

-- Joe Rhett Senior Geek Meer.net

On Wed, Oct 27, 2004 at 01:31:00PM -0400, Barry Warsaw wrote:

On Wed, 2004-10-27 at 13:16, Joe Rhett wrote:

...

It's also simple to run fix_url in a similar manner. So why is the url setting provided with newlist?

newlist predates both fix_url and config_list.

Make sense.

But anyway, my arguement is that having a vanity mailaddr for the list is fairly common (over 90% in most implementations I've seen) so can't we get this put into newlist as being generally useful?

-- Joe Rhett Senior Geek Meer.net

On Oct 27, 2004, at 1:48 PM, Bob Puff@NLE wrote:

...But vanity domains are normally virtualhosts, which already work.
I think it is counter-intuitive to have: Email: list@domain and then have the web interface be at: http://some.other.domain/some other folder/list

Normally they may be virtual hosts, but not *always*. I know I host some lists for people whose web domains aren't hosted on the same machine. I gather paying to host lists can be quite a bit more expensive than web hosting, so I imagine a number of people host lists on DSL and such while their websites are hosted somewhere more stable.
While it's quite reasonable to set up redirects and such, if you're going for lower-cost web hosting, you may not have the option to do so.

Anyhow, for all that making newlist have some extra options *isn't* necessary, it seems like it'll make it that much more useful, so we might as well just do it. It's not like anyone has to use the extra options if they don't want to, and the whole thing can be backwards compatible.

Terri

I'm -0 on it. I think it's generally not needed given all the other tools at your disposal, but if a patch is provided that does this in a clean, backward compatible way, I won't veto it.

What tools are those? A heavy web ui?

Sorry, did I overlook a command/command/command/commit ability in Mailman?

Without that, you are limited to a long chain of command lines where we have to check each return code and then back out the commands if any one fails. This makes no sense for any automation effort, and generally requires several hundred lines of code that do not survive upgrades, to work around a problem that can be solved in several lines of python in the source.

-- Joe Rhett Senior Geek Meer.net

We use config_list to set some specific options for each of our lists.
We have completely automated the mailman list setup and it has worked without any human intervention for our 5000+ lists. Just create a config_list template file by outputting the configuration for an existing list and then write your script to set the variables you want and then load those into the list.

Yes, yes, with many lines of code I can output from an existing list (and check return code and validate the data just in case that list is foobar) and then parse/replace variables, and then reload those into the list and again check return codes and validate everything works.

In fact, I have already done all of that work. I did it differently, by invoking newlist and then using just the new parameters with config_list. I was wondering if I should submit it for the contrib section.

Then, it struck me that this entire 180 lines script could be completely replaced by a single option on the newlist command. And that single option would be useful for many different environments, without any of the built-in assumptions that a script like yours or mine has to make.

So I'm not trying to say: make this work for me -- already does

I am trying to say: This is too much work for how simple the solution is, and a general purpose solution would solve the problem for many, many sites.

-- Joe Rhett Senior Geek Meer.net

Already did it, as stated in my other post. If you are hacking around on your friend's websites it might be "a few lines", but a production script that must either succeed or tell you why not in useful terms takes hundreds of lines.

But then I doubt that people who can't think beyond their personal system hosting their friends websites really grasp the goals I am trying to meet anyway.

And no, you can't code it in Python without wrapping the python script execution in a language that handles exceptions in a useful manner. I'm not a language bigot (kindof hard these days, I work in 5 different languages daily) but if a language doesn't have the ability to do something then you must write wrappers around it.

On Fri, Oct 29, 2004 at 10:48:07AM -0400, Barry Warsaw wrote:

On Thu, 2004-10-28 at 00:03, Joe Rhett wrote:

...

What tools are those? A heavy web ui?

Personally, I'd write a scriptlet for bin/withlist to do it. Should be just a few lines of Python since withlist takes care of getting everything set up properly, deals with lock, etc.

config_list as someone else mentioned is a fine way to go (remember that its input only needs to contain the variables that you want to change).

The other thing to remember is that there's nothing magical about the bin scripts that come with Mailman. They serve as fine examples of how to interact with Mailman from the command line. A Python programmer should have no trouble writing custom scripts to deal with any odd situation that can't already be handled by withlist or config_list.

-Barry

-- Joe Rhett Senior Geek Meer.net

On Wed, 2004-10-27 at 23:59, Joe Rhett wrote:

A virtual host requires me to configure my server to answer mail for their entire domain.

Really? I provide mailing list services for lots of my friend's bands (and most of my own), and they only need to create a new host name in their domain, and point that at my server. I only need to answer mail and web for that host. It's easy to set up and almost effortless to administer. YMMV of course.

-Barry

On Fri, Oct 29, 2004 at 10:36:27AM -0400, Barry Warsaw wrote:

Really? I provide mailing list services for lots of my friend's bands (and most of my own), and they only need to create a new host name in their domain, and point that at my server. I only need to answer mail and web for that host. It's easy to set up and almost effortless to administer. YMMV of course.

Because that list is limited to your friends, and is probably less than a thousand, right?

And second, let's think about this:

1. We add an extra option to newlist that allows us to set the listaddr at creation time.

   -or-

2. You have the list owner change their DNS to point to you

3. You host their website and their domain

4. You provide a mechanism for them to update their web pages

5. You provide a mechanism for them to access their e-mail

6. You become a general support/ISP for said domain, even though you only agreed to host a list for them.

Ah, I see. The latter is OBVIOUSLY a much better idea!

Seriously people, if you have a single server that does everything and you want to host your friend's e-mail lists on it then yes, virtual hosting makes sense. If you are not in the business of providing support and general web hosting to the world at large for free, this is nonsense.

-- Joe Rhett Senior Geek Meer.net

On Fri, Oct 29, 2004 at 06:17:04PM -0400, Barry Warsaw wrote:

On Fri, 2004-10-29 at 18:09, Joe Rhett wrote:

...

And second, let's think about this:

Sorry, I'm out of time to discuss this thread, so I'll just leave it at this: I've already given my vote on doing this in a backward compatible way. What's left is to generate a patch that satisfies my earlier requirements, and then sweet talk Tokio into commit it. :)

That's fine. Since we're sticking with the obscure, unintuitive syntax (to maintain backwards compatibility for an option that not a single person on the list said that they used and most didn't even understand) could I persuade you to update the documentation to state clearly that listname@domain.name is not an e-mail address, but a shortcut syntax to set the admin url to be http://domain.name/admin/listname?

It's still godawful, and near useless.

-- Joe Rhett Senior Geek Meer.net

Hi,

Barry Warsaw wrote:

On Fri, 2004-10-29 at 18:09, Joe Rhett wrote:

...

And second, let's think about this:

Sorry, I'm out of time to discuss this thread, so I'll just leave it at this: I've already given my vote on doing this in a backward compatible way. What's left is to generate a patch that satisfies my earlier requirements, and then sweet talk Tokio into commit it. :)

I am far behind the discussion but I think we can add one more option to newlist command like this:

newlist --urlhost=www.dom.ain --emailhost=mail.dom.ain listname

We also keep @ notation for backward compatibility:

newlist listname@www.dom.ain

Anyone volunteer to make a patch?

-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

Tokio Kikuchi wrote:

I am far behind the discussion but I think we can add one more option to newlist command like this:

newlist --urlhost=www.dom.ain --emailhost=mail.dom.ain listname

We also keep @ notation for backward compatibility:

newlist listname@www.dom.ain

Anyone volunteer to make a patch?

I did. Please check the patch on SF. https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1057579&group_id=103

BTW, newlist listname@dom.ain set both urlhost and _emailhost_ if 'dom.ain' is not defined in VERTUAL_HOSTS.

-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

On Fri, Oct 29, 2004 at 06:23:22PM -0400, Terri Oda wrote:

Nono. You set up mailman.theirdomain.com or lists.theirdomain.com and point *it* at your server. You don't host anything but lists, all the lists then have addresses that are mylist@lists.theirdomain.com and if they want to alias mylist@theirdomain.com, then that's their job and none of your business.

And this still does not solve the original problem I was trying to solve.

The listname is somelist@vanity.com. Creating somelist@lists.vanity.com or somelist@mailman.vanity.com does not solve the original problem. You could go through all the effort of creating this host/domain, and you're still stuck with the problem that the listaddr is not the same as the admin url.

The truth is that I have only rarely witnessed a situation where the listaddr and the hostaddr are the same, except when people are running lists from their own personal computers. That's why I questioned the value the original option.

But anyhow, you seem to have a good idea of what you'd like, and you've clearly got the ability to make the patch if you're handling this stuff right now. Would you be willing to write it? All it takes now is a patch that's good enough for commiting, and you should be able to have what you want.

I'd appreciate anything you could do on this. I want something agreeable and maintained in future versions, including 3.0

-- Joe Rhett Senior Geek Meer.net

On Mon, 2004-10-11 at 13:28, Terri Oda wrote:

On Oct 11, 2004, at 1:31 AM, Joe Rhett wrote:

...

Note that you may want to run bin/fix_url.py to change the domain of an existing list. fix_url.py must be processed by the withlist script, like so: bin/wishlist -l -r bin/fix_url.py <listname>

This sounds more clear to me.

Me too, thanks.

Also, we might want to put this somewhere in the online help for the list admin pages, if it's not already there. I've had a few list admins get confused because there's no setting for it, just a setting for the email domain. I'd suggest that we add a note along these lines to the help for host_name. (eg: "Changing the domain for the web interface must be done from the command line by a site administrator.
See the INSTALL file for more details on how to do this.")

Terri, did I see correctly that you made a checkin to add something like this to the documentation? If so, thanks! I'll try to push out a web site update within a few days.

-Barry

On Oct 17, 2004, at 6:53 PM, Terri Oda wrote:

If anyone's interested looking through the still incomplete site admin docs before Barry puts 'em up, they're available in CVS and can be built to a variety of document formats using the "mkhowto" tool that comes with python's documentation stuff.

I should mention that I've already put these online in various formats so people wouldn't have to do build them themselves:

http://terri.zone12.com/doc/mailman/