Sorry, typo. It's 2.1.13.

On Fri, Aug 27, 2010 at 5:44 AM, Geoff Shang <geoff@quitelikely.com> wrote:

On Thu, 26 Aug 2010, W. Curtis Preston wrote:

I am running the Cpanel version of Mailman, version 2.1.3, which I'm

...

surprised to learn is actually more recent than the version running this mailing list (2.1.2)!

The version that runs this list is 2.1.12. Did you perhaps mean 2.1.13 or did you actually mean 2.1.3?

If it's really 2.1.3, it's rather old.

Geoff.

---

Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/curtis%40backupcentral....

What I know is that the bottom of the screen where it displays the version number says 2.1.13 and nothing more.

Any thoughts on my URL problem? Any chance you have a "real" 2.1.13 install out there we can test it on?

On Fri, Aug 27, 2010 at 10:27 PM, Brad Knowles <brad@shub-internet.org>wrote:

On Aug 27, 2010, at 11:46 AM, W. Curtis Preston wrote:

...

Sorry, typo. It's 2.1.13.

Are you sure it's 2.1.13, and not something like 2.1.11-cp3? In all the versions I've ever seen cPanel release, they've always included a dash and then their internal version identifier for their modified code.

If they are now shipping something and calling it 2.1.13 and it's not exactly the same code that we provide from < http://www.list.org/download.html>, then I think it's time we had the PSF and/or FSF lawyers give them a call -- and speaking as a member of the Mailman Cabal, I will make sure to carry through on that, if necessary.

-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>

Waiting with bated breath. ;)

On Fri, Aug 27, 2010 at 10:43 PM, Brad Knowles <brad@shub-internet.org>wrote:

On Aug 28, 2010, at 12:35 AM, W. Curtis Preston wrote:

...

What I know is that the bottom of the screen where it displays the version number says 2.1.13 and nothing more.

Any thoughts on my URL problem? Any chance you have a "real" 2.1.13 install out there we can test it on?

I'm sure that Mark and Barry have "real" 2.1.13 systems out there that this could be tested with, but I do not currently have access to such myself, at least not in any kind of publicly accessible place.

I am sorely tempted to log onto mail.python.org and do the upgrade right then and there, and make sure that we eat our own dogfood. However, I really should coordinate this with the guys who've been doing the day-to-day administration of mail.python.org for the past several months. Let me see how quickly we can get that upgrade done.

-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>

On Aug 28, 2010, at 10:05 AM, Mark Sapiro wrote:

Just FYI, 2.1.14 is going to be released next month. You might want to wait.

I've been totally out of the loop for way too long. I need to get back up to speed and see what is changing and how that might affect our operations for python.org.

Thanks for the heads-up!

-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>

On 8/28/2010 2:24 AM, William Bagwell wrote:

I can confirm that a cPanel Mailman install that recently was 2.1.11.cp3 is now showing 2.1.13 in the headers.

Thanks for the confirmation.

I think Mark has seen their code and is working to have a better relationship with them... Ah, see this post. http://www.mail-archive.com/mailman-users%40python.org/msg56847.html

I would love to have a better relationship with the cPanel Mailman folks, but I have none. They don't acknowledge me at all. Anything I know about cPanel Mailman internals is via code provided to me by 3rd parties.

Please don't threaten to sue them! I want Mailman 3.0 and the only way I,m going to get to use it is through cPanel.

All we would ask is that they continue their past practice of identifying their modified Mailman as, e.g. 2.1.13-cp1 so that we know what we're dealing with.

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

--On August 28, 2010 10:32:15 AM -0500 Brad Knowles <brad@shub-internet.org> wrote:

After that, we might think about whether or not we can, or should, go after Apple. Both companies are shipping our code with extensive modifications, and so far as I know neither of them has released their changes, as required by the GNU license.

To which I reply:

For what it's worth, I dif'd Apple's Mailman code against the stock code at one point, and I wouldn't describe the changes as extensive. The primary change was the addition of a version of 'mailmanctl start' that wouldn't daemonize, in order to work properly with Apple's launchd.

-- Steve Burling <mailto:srb@umich.edu> University of Michigan, ICPSR Voice: +1 734 615.3779 330 Packard Street FAX: +1 734 647.8700 Ann Arbor, MI 48104-2910

On Sat, 28 Aug 2010, Mark Sapiro wrote:

On 8/28/2010 2:24 AM, William Bagwell wrote:

...

I can confirm that a cPanel Mailman install that recently was 2.1.11.cp3 is now showing 2.1.13 in the headers.

Thanks for the confirmation.

I can also confirm that a site which was previously running Mailman 2.1.12.cp3 (in fact the site I sent Mark a diff from) now seems to be running 2.1.13 with no cp designation. From what I know of the operation, I think it highly unlikely that the hoster would have changed from using CPanel, and the list pages are still using the virtual host form used by CPanel Mailman.

Here is a publicly-accessible listinfo page: http://blindtech-list.info/mailman/listinfo/blindtech_blindtech-list.info

Geoff.

On Aug 29, 2010, at 9:59 AM, Todd Zullinger wrote:

I'm not arguing that if a distributor patches Mailman and changes core behavior to the point that it causes confusion for users and potentially sullies Mailman's reputation that it's fine and should be left alone. Just trying to see what grounds on which you want the lawyers to complain.

If a vendor is changing where files are stored and nothing else, then I don't think there's anything to complain about -- all code may need a certain amount of customization to fit into a different filesystem structure. I think that we can account for those kinds of changes with nothing more than different sets of parameters that go into the configuration file.

If they can share those kinds of changes with us, we may be able to incorporate them into an upcoming version of the code we release, so that next time one of their customers may be able to upgrade with a command that is basically just "./configure; ./install; /path/to/mailmanctl restart". That would be a win-win-win scenario -- a win for the customer, a win for the vendor, and a win for us.

However, if a vendor is changing underlying application functionality, that would be something I would be much more concerned about. If it's just keeping the code from daemonizing when they do a "mailmanctl start", I think that's something we could accommodate with a future version of our code -- and then we can get back to that win-win-win scenario mentioned above. If there's more to it than that, then I would definitely be inclined to be much tougher in my response.

-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>

Stephen J. Turnbull wrote:

Under the GPL, you don't have any grounds for anything except the kind of campaign that might open you up to a libel suit as long as they're distributing source with the binary versions. The GPL doesn't require that version numbers be munged by downstream, and I don't think you can trademark a version number.

I don't like cPanel's way of operating, and I agree that Apple's interaction with the open source community *outside of Darwin* takes a lot more out than it puts back in. Still, the GPL doesn't give any cause for action AFAICS.

Agreed. I think the main alternative is using trademarks, like Mozilla does. That's not very popular with the very folks that do support open source code well though. Debian doesn't ship Firefox because of this. And Fedora sometimes has to work harder than they should to get patches accepted upstream before they can be shipped as part of the distro.

I tend to think that solution causes more harm than good, no matter how well-intentioned it may be.

-- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp

A common mistake people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
    -- Douglas Adams

On Aug 29, 2010, at 7:50 PM, Stephen J. Turnbull wrote:

I don't like cPanel's way of operating, and I agree that Apple's interaction with the open source community *outside of Darwin* takes a lot more out than it puts back in. Still, the GPL doesn't give any cause for action AFAICS.

If there are no courses of action open to us in the courts in these matters, then in such cases I might be inclined to think that a suitably crafted and executed PR campaign would be an alternative to be considered.

But setting aside all of the things in this thread that have been said so far, I would like to point out that I have not made any irrevocable decisions on the matter, and I have yet to take any actual action. I've spoken about what my tendencies and inclinations would be, nothing more.

-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>

On Aug 29, 2010, at 9:59 AM, Todd Zullinger wrote:

I'm not arguing that if a distributor patches Mailman and changes core behavior to the point that it causes confusion for users and potentially sullies Mailman's reputation that it's fine and should be left alone. Just trying to see what grounds on which you want the lawyers to complain.

Oh, and for me, it has nothing to do with sullying our reputation. It has much more to do with crippling our ability to support our customers, because experience has taught us that many of these vendors want to ship code without providing any of the actual support costs.

If they're going to externalize onto us (a non-profit, unpaid, volunteer organization) all of their customer support costs for this part of their commercial package that they may sell for large sums of money, then as I see it they owe us one of two things:

1. Payment of money and other significant physical resources to provide the customer support that they are unable or unwilling to provide themselves

2. At least contribute all their code changes back to us so that our additional cost is minimized to support all their customers that they are unable or unwilling to support themselves

Otherwise, in my mind, they are quite literally stealing from the community, and they should suffer the criminal and civil court consequences.

This is not to say that all vendors necessarily want to externalize all their support costs onto us, but that there are significant numbers of vendors who want to ship sewage out the door and put a hefty price tag on it, and they do everything they possibly can to make sure that none of their customers can come back to them and actually receive adequate support for the effluent that was delivered.

In those cases, the collateral damage to the community is a very real cost that we all have to bear our part of, just so that the company can make good on their get-rich-quick scheme, which they perpetrate at the expense of everyone else.

-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>

I asked my hosting company liquidweb to talk to cpanel. Liquidweb has always given me great support (24x7 I might add), but at this point they are at a loss and are as much at the whim of cpanel as I am.

Since they do not appear to distribute the source of Mailman with cpanel (at least I can't find it), I have asked Liquidweb to ask cpanel to provide it. In addition, I have asked them to explain why a "real" install of Mailman can do what I'm asking and there's can't.

I will keep you abreast of the responses.

On Sun, Aug 29, 2010 at 8:43 PM, W. Curtis Preston <curtis@backupcentral.com

wrote:

On Sun, Aug 29, 2010 at 3:34 PM, Brad Knowles <brad@shub-internet.org>wrote:

...

Oh, and for me, it has nothing to do with sullying our reputation. It has much more to do with crippling our ability to support our customers, because experience has taught us that many of these vendors want to ship code without providing any of the actual support costs.

If they're going to externalize onto us (a non-profit, unpaid, volunteer organization) all of their customer support costs for this part of their commercial package that they may sell for large sums of money, then as I see it they owe us one of two things:

Brad you bring up a good point that I don't think everyone is aware of. Those of using a "commercial distro" of Mailman should get our support for said installation said group. I suppose if I was doing something normal, I would. However, I didn't even think to ask them because I figured the answer would be "You're trying to do WHAT?" Well, that's not supported...

But you know what? I never even asked, so I think I will.

Mark,

I did see that answer, and did use rawurlencode to encode the email strings, and it's still not working.

On Wed, Sep 1, 2010 at 6:52 AM, Mark Sapiro <mark@msapiro.net> wrote:

W. Curtis Preston wrote:

...

I asked my hosting company liquidweb to talk to cpanel. Liquidweb has always given me great support (24x7 I might add), but at this point they are at a loss and are as much at the whim of cpanel as I am.

Since they do not appear to distribute the source of Mailman with cpanel (at least I can't find it), I have asked Liquidweb to ask cpanel to provide it. In addition, I have asked them to explain why a "real" install of Mailman can do what I'm asking and there's can't.

Your problem has nothing to do with cPanel. Perhaps the answer got lost in the noise, but you can find it at <http://mail.python.org/pipermail/mailman-users/2010-August/070157.html>.

WRT cPanel source, the most significant mods are their own list creation process and their mailman router for exim. See <http://mail.python.org/pipermail/mailman-users/2010-April/069269.html>

cPanel's mailman installation is at /usr/local/cpanel/3rdparty/mailman on the cPanel server as noted in our FAQ at <http://wiki.list.org/x/sYA9>.

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

Mark,

I really appreciate your assistance on this.

I did look at the source for the members page, which is how I constructed the GET query in the first place.

The only thing that changed on this page changed between Mailman 2.1.9

and 2.1.10 and that was the encoding of '@' as '%40' in the email addresses, and also encoding of a few other characters, double-quote in particular.

I understand that.

Ther chould be no differences between cPanel's page and the corresponding upstream Mailman page.

I agree. I don't think so either.

I note in your original post, you said:

...

First you have to subscribe them, then you would issue the following URL:

http://<domain>/mailman/admin/<listname>/members?user=<email-address>& <email-address> _digest=1&setmemberopts_btn=Submit%20Your%20Changes&allmodbit_val=0& <email-address>_language=en&<email-address>_nodupes=1&adminpw= <adminpassword>

This has also worked for a few years, but I just found out that it isn't working. I can set someone to digest mode by manually accessing that same page, but the URL no longer does the job. When I issue the URL manually in my browser, instead of setting the user to digest mode and returning me to the screen with the user on it, it returns me to the /members page, displaying a list of users.

Which is exactly what I would expect. That URL is equivalent to checking the user's 'digest box on the membership list and clicking Submit Your Changes. It will normally return to the same page.

I believe what I should be seeing is what happens when you enter a user's email address in the search box and THEN click the digest button. I should see the list of just the user I'm setting, and the check box for digest should be checked. But that's not what's happening. I get returned to the default members list (not just the list of the member I'm working on) and then if I check the user I was trying to set, the digest box is not checked. I'm not complaining so much about what screen I get taken to, but that it's not setting the digest mode for the user, even though I'm using the new encoded email addresses in my GET query.

I have not looked to see if this is an issue, but there is one

potential glitch. If the number of list members exceeds admin_member_chunksize, there will be an additional query fragment in the URL like

http://<domain>/mailman/admin/<listname>/members?letter="u"

for an email address beginning with "u". In fact it can be even more complex if the number of users beginning with a single letter exceeds admin_member_chunksize.

Again I'm not having a problem interpreting what is being displayed on the screen. I'm having a problem that I can't set the digest mode via this URL that appears to be valid:

http:// <domain>/mailman/admin/<listname>/members?user=<email-address>&<email-address>_digest=1&setmemberopts_btn=Submit%20Your%20Changes&allmodbit_val=0&<email-address>_language=en&<email-address>_nodupes=1&adminpw=><adminpassword>

This URL used to work and now it doesn't, even if I use the new style of email addresses. I've also tried to do things like emailaddress_digest=on/off instead of 1/0, but that doesn't seem to help either. I just can't seem to figure out the magic incantation. ;)

TIA for any help.

So it seems I misunderstood your previous post. Sorry about that. I followed your suggestion. Both of them, actually. I tried all of the following URLs, to no avail. The first two do at least display just the username in question. I did change the chunksize variable and did the latter two URLs, and that didn't work either. (In case it's not obvious, I tried using the values off/on and 0/1 in case that was the problem.)

http://domain.com/mailman/admin/listname/members?findmember=username%40gmail.com&user=username%40gmail.com&username%40gmail.com_unsub=0&username%40gmail.com_mod=0&username%40gmail.com_hide=0&username%40gmail.com_nomail=0&username%40gmail.com_ack=0&username%40gmail.com_notmetoo=0&username%40gmail.com_nodupes=0&username%40gmail.com_digest=1&username%40gmail.com_plain=0&username%40gmail.com_language=en&setmemberopts_btn=Submit%20Your%20Changes&allmodbit_val=0&adminpw=password

http://domain.com/mailman/admin/listname/members?findmember=username%40gmail.com&user=username%40gmail.com&username%40gmail.com_unsub=off&username%40gmail.com_mod=off&username%40gmail.com_hide=off&username%40gmail.com_nomail=off&username%40gmail.com_ack=off&username%40gmail.com_notmetoo=off&username%40gmail.com_nodupes=off&username%40gmail.com_digest=on&username%40gmail.com_plain=off&username%40gmail.com_language=en&setmemberopts_btn=Submit%20Your%20Changes&allmodbit_val=off&adminpw=password

http://domain.com/mailman/admin/listname/members?user=username%40gmail.com&username%40gmail.com_unsub=off&username%40gmail.com_mod=off&username%40gmail.com_hide=off&username%40gmail.com_nomail=off&username%40gmail.com_ack=off&username%40gmail.com_notmetoo=off&username%40gmail.com_nodupes=off&username%40gmail.com_digest=on&username%40gmail.com_plain=off&username%40gmail.com_language=en&setmemberopts_btn=Submit%20Your%20Changes&allmodbit_val=0&adminpw=password

http://domain.com/mailman/admin/listname/members?user=username%40gmail.com&username%40gmail.com_unsub=0&username%40gmail.com_mod=0&username%40gmail.com_hide=0&username%40gmail.com_nomail=0&username%40gmail.com_ack=0&username%40gmail.com_notmetoo=0&username%40gmail.com_nodupes=0&username%40gmail.com_digest=1&username%40gmail.com_plain=0&username%40gmail.com_language=en&setmemberopts_btn=Submit%20Your%20Changes&allmodbit_val=0&adminpw=password

On Fri, 3 Sep 2010, Brad Knowles wrote:

I'm sure Mark will correct me if I'm wrong, but I assume you stopped and restarted Mailman after making the chunksize change? I don't think that this is something that is baked into the list when it's created, but is instead something that can be changed after-the-fact, and all that should be required is a restart.

I doubt this needs a restart, as member chunk size is something a list owner can change on the admin pages.

Geoff.

W. Curtis Preston wrote:

So it seems I misunderstood your previous post. Sorry about that. I followed your suggestion. Both of them, actually. I tried all of the following URLs, to no avail. The first two do at least display just the username in question. I did change the chunksize variable and did the latter two URLs, and that didn't work either. (In case it's not obvious, I tried using the values off/on and 0/1 in case that was the problem.)

I finally had some time to devote to debugging this, and I know what the problem is. The 2.1.10 change was made because the local part of an email address can be quoted with a double quote as in "john&jane"@example.com. The presence of those double quotes would break the HTML for the membership list page by creating things like

<INPUT name=""john&jane"@example.com_nomail" type="CHECKBOX" value="on" ...

This was avoided by quoting the email address so the above would become

<INPUT name="%22john%26jane%22%40example.com_nomail" type="CHECKBOX" value="on" ...

However, this means the CGI script now expects field names to be quoted as above.

The problem in this case is that when you specify these parameters as query fragments in the URL, the Python class that Mailman uses to retrieve the parameters unquotes the query fragments, whereas it doesn't do this with POST data. This means the admin CGI script is looking for things like user%40example.com_nomail, and if they are provided as POST data, that's what it sees, but if they are provided as query fragments of a GET URL, it sees user@example.com_nomail which doesn't work.

This means instead of giving the email as user%40example.com in a URL query fragment, you need to give it as user%2540example.com which will result in the %25 being changed to % and the script seeing user%40example.com.

Note also that you can subscribe the user and set options with a single GET URL. For example:

http://<domain>/mailman/admin/<list>/members/add?subscribe_or_invite=0&send_welcome_msg_to_this_batch=0&send_notifications_to_list_owner=0&subscribees=user@example.com&user=user%2540example.com&user%2540example.com_digest=1&user%2540example.com_nodupes=1&user%2540example.com_plain=1&setmemberopts_btn=1&adminpw=<password>

Note the following:

I have specified subscribees instead of subscribees_upload as in the OP. This doesn't matter; either will work, but subscribees is shorter. Note the address here is raw, not encoded.

I have corrected send_notifications_to_list_owner which was notification_to_list_owner in the OP.

I have omitted allmodbit_val=0 since this is ignored unless allmodbit_btn is present.

I have setmemberopts_btn=1 since the actual value is ignored - only the presence or absence of the key is significant.

I have omitted the '=0' option settings. In most cases (language is an exception), ommitting a setting is the same as setting it to unchecked or empty. This does mean that settings which are on by default must be explicitly set whether you do it with one step or two or they will be turned off. The exception is language which will be unchanged if omitted.

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

All I can say is http://www.backupcentral.com/ha.mp3 !!!!

It works! Thank you so much for your help with this!

The following URL will set an existing user's digest flag on and nothing else: http://domain.com/mailman/admin/listname/members?user=user%2540gmail.com&user%2540gmail.com_digest=1&setmemberopts_btn=1&adminpw=password

The opposite (digest=0) doesn't turn it off. I don't need it for me, but I am curious about your thoughts on that, as I plan to help update the FAQ with what we've learned here.

The other tip you gave also works: http://<domain>/mailman/admin/

<list>/members/add?subscribe_or_invite=0&send_welcome_msg_to_this_batch=0&send_notifications_to_list_owner=0&subscribees= user@example.com&user=user%2540example.com &user%2540example.com_digest=1&user%2540example.com_nodupes=1&user%2540example.com_plain=1&setmemberopts_btn=1&adminpw=<password>

That does indeed subscribe them and set them to digest mode. That will simplify my code.

Did I mention this is what I'm hearing: http://www.backupcentral.com/ha.mp3??

Thanks, Mark. Your internal knowledge of Mailman was really needed to figure this out. You could have just said "Dude, that's not really how Mailman was meant to be used..." but you didn't. Thank you, thank you, thank you.