Mailman 3 July 2001 - Mailman-Developers

Re: [Mailman-Developers] Re: GET vs POST (was Re: subscription confirmations)
by J C Lawrence 19 Jul '01

19 Jul '01

On Wed, 18 Jul 2001 21:56:28 -0700 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > On 7/18/01 9:51 PM, "J C Lawrence" <claw(a)2wire.com> wrote: >> http://www.google.com/search?q=beej+site%3Awww.kanga.nu > Wait. Are we allowed to put this in an e-mail? Shouldn't JC have > had to put it on a web page and post a URL to the page with the > link on it? <bang!> What a senseless waste of human life! -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw(a)kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly

2 1

Re: [Mailman-Developers] Re: GET vs POST (was Re: subscription confirmations)
by Ben Burnett 19 Jul '01

19 Jul '01

Re: [Mailman-Developers] Re: GET vs POST (was Re: subscription confirmations) ------- Original Copy ------- >Subject: Re: [Mailman-Developers] Re: GET vs POST (was Re: subscription confirmations) >Date: 07/18/2001 4:01 PM >From: "Jay R. Ashworth" <jra(a)baylink.com> >To: mailman-developers(a)python.org >On Wed, Jul 18, 2001 at 12:51:28PM -0700, Chuq Von Rospach wrote: >> On 7/18/01 12:32 PM, "Jay R. Ashworth" <jra(a)baylink.com> wrote: >> > Alas, this is *just like* making the GET active, only worse. >> >> How? I'm confused. Either way, you end up at a page with the confirmation >> information and an "accept" button (or use whatever terminology you want). >> >> If you think that's wrong, what do you think would work? I'm lost where >> you're headed here. > >The two suggested approaches were, as I understood them, a URL embedded >in the mail with a GET that was active and actually *did* the >unsibscribe, and a URL embedded in the mail with a "pseudo-GET"; that >is, there is no "?", but the URL is *still* magic, and performs the >action when the URL is retrieved. This is not the impression that I had I thought we were discussing two different possibilities. 1) the way it is done now. visit the link (inherently a get operation) and you are unsubscribed (or subscribed as the case may be). The page that you see when you visit this link tells you that the unsubscribe operation has been performed. 2) the way C3C wants it done. visit the link (still a get operation) and you are taken to a page where you have to submit a form in order to have the unsubscribe operation performed. > >If I correctly understood your latter suggestion, then that's even >worse, because 'scoopers' can't even avoid it -- it's not marked as >'magic' by the "?" character in the URL. It appears as though you might be mistaken as to what constitutes a GET request. Here is a multiple choice question to make sure we are all on the same page. Which of the following URLs is uses the GET method. x. http://host.domain.com/script.cgi?param=value y. http://host.domain.com/script.cgi z. http://host.domain.com/script.cgi/pathinfo?id=12 a) x. b) y. c) z. d) all of the above. e) none of the above. f) it depends on how the HTTP Client calls the url. The way I understand it the answer is "f) it depends on how the HTTP Client calls the url.". Having a "?" character does not determine wether a url will be called using GET or POST or any other method. Methods listed in RFC 2616 for HTTP 1.1 include OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT, extension-method ( extension-method = token ) (see ftp://ftp.isi.edu/in-notes/rfc2616.txt section 5.1.1 for more details on methods) There are specifications on what each method is supposed to be used for (indeed this is what were discussing), but there is nothing to keep someone from misusing a method (as is shown by Mailman's own ?mis?use.) An interesting thing about specifications is that their value decreases as the number of infringements against them increases. And their value increases as the number of compliances increases. As far as I know most (if not all) mail clients that allow the user to visit a URL embedded in an email use the GET method to fetch that URL. But the only things keeping someone from building an email client that used the POST method are rfc 2616 and the wrath of Gerald and the W3C army. For what it's worth I like option 2. - It requires the user to make a more definite step towards subscribing/unsubscribing. - it exposes "naive" users to more technological steps without being overly confusing. (more exposure=good) - it complies with the W3C spec. As far as whether the specification in this instance is good or valuable. I don't think it's a simple cut and dried matter, and I'll give it some more thought and hopefully . - Ben

3 2

Re: [Mailman-Developers] Re: GET vs POST (was Re: subscription confirmations)
by Jay R. Ashworth 19 Jul '01

19 Jul '01

On Wed, Jul 18, 2001 at 08:27:15AM -0700, Chuq Von Rospach wrote: > You have to step back and stop thinking that the people using these systems > are (a) computer people, (b) think like you do, and [c] actually understand > how these systems work and can guess what it takes to jump through your > hoops. They don't. Every chance you give them to get it wrong, some will. > Not everyone is a geek (or wants to be), not everyone is an > english-first-language speaker, not everyone has experience in mail lists, > not everyone can easily read instructions and translate them into a > requested action. They need handholding, not because their stupid, but > because we've done a lousy job of building systems that don't require them > to be geeks, and then we blame THEM for not being geeks. I wish to ... what's the opposite of concur? :-) with your learned opinion on this specific point, Chuq. I'm afraid there *are* *lots* of people on the internet for whom "stupid" is not an epithet, but merely descriptive. They really are. They won't, don't or can't read, think, and understand things. Things as simple as "please click this button to confirm that you want to be added to this list. If you don't, you don't need to do anything at all". Which is, is it not, what we were talking about in the first place... I'm sorry, but when it gets that simple, I can't attribute it to ignorance, or lach of technical inclination. It is just stupidity. We asked for it. We're getting it. "So easy to use, it's no *wonder* the Internet is going to hell!" Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 OS X: Because making Unix user-friendly was easier than debugging Windows -- Simon Slavin in a.f.c

4 12

module imports & performance
by Ricardo F . Kustner 18 Jul '01

18 Jul '01

Hi, I finally was forced to upgrade my ancient slackware/libc5/linux2.0 system on which I'm running mailman (among other stuff) since the (old) disks were actually about to vaporize. The rest of the hardware stayed low-end (Pentium 90 with 64mb memory)... the new installation is running Progeny Debian 1.0, kernel 2.2.18 and Python 1.5.2 on a fresh new disk. I've installed mailman 2.0.5 straight from the source (package systems are great but for some apps I still prefer to compile it myself) Most of the components (apache,fastcgi,php and some perl scripts) don't show any difference in performance, but it looks like the mailman python scripts have decreased in performance dramatically... loading up a page in the webinterface takes about 7 seconds! After some playing around with python -i, I noticed that "from Mailman import MailList" takes about 4 seconds... Does anybody have any idea what's going on? maybe the python binary compiled into Debian isn't optimized enough for my system or could this be a problem in mailman? Regards, Ricardo

3 3

Re: [Mailman-Developers] Re: GET vs POST (was Re: subscription confirmations)
by Les Niles 18 Jul '01

18 Jul '01

On Wed, 18 Jul 2001 08:27:15 -0700 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: >On 7/18/01 7:56 AM, "Les Niles" <les(a)2pi.org> wrote: > >>> There is much reason not to comply with the published standard: people >>> are stupid. Shame, isn't it? >> >> I'm not sure which stupidity you're talking about. Are you >> concerned that people will launch the link from the email but then >> not push the "confirm" (or "cancel") button? > >I won't use the word "stupid" -- because it's not really the right word. But >unskilled, or naïve is. Absolutely -- I would never refer to the set of users that have problems with the mailing lists as "stupid." Unskilled, or unfamiliar with this electronic communications paradigm, yes, but the individuals are almost never truly stupid (which is a gross and mostly irrelevant measure anyway). I happen to run mailing lists where most of the subscribers have demonstrated some significant technical savvy, but nothing to do with computers. A small but non-zero percentage just couldn't deal with the mail-back confirmation, even with a lot of handholding. That's why I hacked up the confirm-by-GETting patch in the first place. One of the not-uncommon characteristics that I've noticed about novices is to adopt a semi-random reading/browsing style. That is, given a page, whether a web page or an email message, containing chunks of text and various links, they'll tend to read the text blocks and visit the links in a somewhat random order. This is not unreasonable given the design of a lot of web pages, and is almost encouraged by the hypertext model in the first place. Since links in email are rendered as just a textual URL, such a user will have about a 50-50 chance of clicking the confirm-subscription link before reading about what it does. I guess that's the main reason I think that launching a page with a couple of big, fat, clearly-labeled POST buttons to do the actual confirm/don't confirm is a better UI. Unix hard-cores like myself -- the sort who use aliases because the 3-character command names are too much to type -- will chafe at the extra mouse click that's required, but we'll deal with it. -les

1 0

Suggestion to add multiple language support
by Max Yu 18 Jul '01

18 Jul '01

Hi, Currently Mailman only supports English, this is not very convenient to average people living outside English spoken countries. So maybe it will be great help if Mailman can support other languages, and let users choose which language he wants to use. I guess this may need to add more templates directory in the source tree, one directory for a language. Or something like that. I can help to write templates for Simplified Chinese, if you need it. Thanks. Best Regards, Max

4 3

unsubscribe
by angeles.moreno＠senado.es 18 Jul '01

18 Jul '01

unsubscribe

1 0

Re: [Mailman-Developers] Re: [Mailman-Users] [ANNOUNCE] Mailman 2.1 alpha 2
by J C Lawrence 17 Jul '01

17 Jul '01

On Tue, 17 Jul 2001 10:34:22 +0200 Thomas Wouters <thomas(a)xs4all.net> wrote: > After some careful consideration, as well as a chat with a few > clueful colleagues, I have to disagree with you, Barry. The trick > here is 'managing the expectations'. Having the message say > something like > To confirm or remove your subscription request, visit <URL> > And then have that URL bring up a nice overview of what list you > are subscribing to, the options you chose > (regular-digest/mime-digest/etc), what email address you entered, > and 'remove' and 'confirm' buttons. Agreed. Which is the greater value: Yet more automated hand-holding for the uncertain/unfacile or Faster and more direct operation for the masses >From a list owner perspective I know which side I'd prefer. > Frankly, it's always bothered me that you can't unconfirm a > mailinglist subscription, let alone not being able to see what you > are subscribing to ;P <nod> > Extra credit if you make the URL (or something similar) also work > if a subscription is held for approval, but without a 'confirm' > button -- just a 'remove' one. Actually, the same kind of > interface for a held message would be great, too :) Yup, especially the latter (I have several who persist in sending in dupes before they remember its a hand moderated list). -- J C Lawrence ("`-''-/").___..--''"`-._ ---------(*) `6_ 6 ) `-. ( ).`-.__.`) claw(a)kanga.nu (_Y_.)' ._ ) `._ `. ``-..-' http://www.kanga.nu/~claw/ _..`--'_..-_/ /--'_.' ,' I never claimed I was human (il),-'' (li),' ((!.-'

1 0

Bug in Mailman version 2.1a2: confirm+approve via URL
by Georg Koch 17 Jul '01

17 Jul '01

Hi developers, when a user tries to confirms a subscription request for a list with "confirm+approve" subscription poliy via the URL given in the "confirm" email, he hits a bug (see attachment). The administrator is notified about a subcription request but does not find one in the administrative database. Who helps? Georg Koch -- Georg Koch ( mailto:gorg@cochrane.de ) | Phone: +49 761 203 6710 German Cochrane Centre | Fax: +49 761 203 6712 Mail: Institute of Medical Biometry and Medical Informatics Stefan-Meier-Strasse 26, D-79104 Freiburg, Germany ...................................................................... Crossing the Quality Chasm: A New Health System for the 21st Century http://www.nap.edu/books/0309072808/html/

1 0

Re: [Mailman-Developers] Please Explain !!!
by Simon Troup 16 Jul '01

16 Jul '01

> Possible theorem: > Someone who owns or has compromised the sardy5(a)graffiti.net account is > using it and its .forward file to mailbomb you. > > Have you tried sending it an unsubscribe message or complaining to the > listowner? Well, failing anything else that is what I'll do, although I am a little tentative about mailing any mailing list after the thousands of subscribe failure notices I was sent (when I didn't subscribe). I'm no goody two shoes but I doubt a tech minded enemy is doing this to me, it doesn't make any sense. Oh well I'm going to bite the bullet and try to unsubscribe. I do have options (mail block etc) but I thought you guys would want to know about things like this, and frankly I was curious why it happened so I could stop it happening again. I realise that this is not the fault of python.org or mailman, but somehow my signing up to a list with python.org instigated a bizarre mixup or attack via sardy5(a)graffiti.net My thanks to all those who have looked into this. Simon Troup

1 0