Mailman 3 June 2002 - Mailman-Developers

[ mailman-Patches-574976 ] Reply-To option, Author Name & Archives
by noreply＠sourceforge.net 28 Jun '02

28 Jun '02

Patches item #574976, was opened at 2002-06-28 01:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=574976&group_i… Category: Pipermail Group: None Status: Open Resolution: None Priority: 5 Submitted By: Susan Dridi (sdridi) Assigned to: Nobody/Anonymous (nobody) Summary: Reply-To option, Author Name & Archives Initial Comment: If the option to Reply-To the list is set, and if the "From:" field in the list.mbox file is in the format of "Poster Name" <somebody(a)example.com> or else Poster Name <somebody(a)example.com>then Poster Name is displayed as the Author. If the "From:" field is in the format of someone(a)example.com (AOL does this) then the Author is the list e-mail address. The e-mail address in the archived post is always the list e-mail address. So, it's often difficult to tell who actually posted something. Here is the patch, which just rearranges lines that were already in the code: *** pipermail.py.dist Fri Jun 1 15:30:16 2001 --- pipermail.py Mon Jun 24 12:22:46 2002 *************** *** 176,189 **** # Figure out the e-mail address and poster's name self.author, self.email = message.getaddr('From') ! e = message.getheader('Reply-To') if e is not None: self.email = e self.email = strip_separators(self.email) self.author = strip_separators(self.author) - - if self.author == "": - self.author = self.email # Save the In-Reply-To:, References:, and Message-ID: lines # --- 176,188 ---- # Figure out the e-mail address and poster's name self.author, self.email = message.getaddr('From') ! if self.author == "": ! self.author = self.email ! e = message.getheader('Reply-To') if e is not None: self.email = e self.email = strip_separators(self.email) self.author = strip_separators(self.author) # Save the In-Reply-To:, References:, and Message-ID: lines # ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=574976&group_i…

1 0

[ mailman-Bugs-566150 ] real names
by noreply＠sourceforge.net 27 Jun '02

27 Jun '02

Bugs item #566150, was opened at 2002-06-08 08:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=566150&group_i… Category: None Group: 2.0.x >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Bernhard Kuemel (darsie) Assigned to: Nobody/Anonymous (nobody) Summary: real names Initial Comment: I'd like it if people could enter their real (first, last) name in their subscription. It is nicer to receive mails with ones real name. Thanks, Bernhard ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-06-28 00:25 Message: Logged In: YES user_id=12800 Closing this as it's already supported in Mailman 2.1 (currently in beta testing). It won't be supported in the MM2.0.x series. ---------------------------------------------------------------------- Comment By: Kyle Rhorer (rhorer) Date: 2002-06-28 00:04 Message: Logged In: YES user_id=569903 It is not just nice, it's downright useful. The listadmins of large lists sometimes need to know if a particular person is subscribed, but may only know the person's name. If John Smith is subscribed as bizzyboy938(a)yahoo.com (a ficticious address for the purpose of illustration), the admin won't be able to determine whether Mr. Smith is subscribed or not. It would also be nice if the admin could sort on either real name or email address, but I certainly wouldn't want to see addition of the real name feature held up waiting for the sort capability. Thanks, Kyle ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=566150&group_i…

1 0

[ mailman-Bugs-566150 ] real names
by noreply＠sourceforge.net 27 Jun '02

27 Jun '02

Bugs item #566150, was opened at 2002-06-08 07:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=566150&group_i… Category: None Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Kuemel (darsie) Assigned to: Nobody/Anonymous (nobody) Summary: real names Initial Comment: I'd like it if people could enter their real (first, last) name in their subscription. It is nicer to receive mails with ones real name. Thanks, Bernhard ---------------------------------------------------------------------- Comment By: Kyle Rhorer (rhorer) Date: 2002-06-27 23:04 Message: Logged In: YES user_id=569903 It is not just nice, it's downright useful. The listadmins of large lists sometimes need to know if a particular person is subscribed, but may only know the person's name. If John Smith is subscribed as bizzyboy938(a)yahoo.com (a ficticious address for the purpose of illustration), the admin won't be able to determine whether Mr. Smith is subscribed or not. It would also be nice if the admin could sort on either real name or email address, but I certainly wouldn't want to see addition of the real name feature held up waiting for the sort capability. Thanks, Kyle ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=566150&group_i…

1 0

[ mailman-Patches-510415 ] Improve MIME header handling
by noreply＠sourceforge.net 27 Jun '02

27 Jun '02

Patches item #510415, was opened at 2002-01-29 18:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=510415&group_i… Category: Pipermail >Group: Mailman 2.1 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Improve MIME header handling Initial Comment: This patch fixes a number of problems for non-English archives. In particular: - it normalizes the encoding name (converting to lower-case, splitting of potential \r characters, and splitting off potential quotes) - if the article and the header encoding differ, it tries to preserve the decoded header as a Unicode string, instead of immediately falling back to the MIME-encoded one (if the encoding is not known to Python it will still fall back) - if a Unicode string needs to be formatted, it uses character references for all non-ASCII characters. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-06-28 00:01 Message: Logged In: YES user_id=12800 k-fish, Martin was actually referring to the revision of one of the files in the Mailman 2.1 distribution. MM2.1 is in beta testing now and will officially support internationalization. The MM2.0.x does not. I'm closing this patch since as Martin says, it's already applied! ---------------------------------------------------------------------- Comment By: Karsten Dambekalns (k-fish) Date: 2002-06-19 18:21 Message: Logged In: YES user_id=105527 Ok, I could have had a look at the patch header more closely, sorry. Thanks for your answer though, I wasn't aware of 2.14 being existent at all, since 2.0.9 seems to be the latest version being officially avilable... Anyway, my problem with german Umlauts being screwed up was solved by running arch manually, somehow the Umlauts seems to be only messed up when the archiver is run automatically... And rather than backporting (especially now, since my special problem was solved so easily ;) I would love to see a newer version of mailman being released officially... Thanks again for you answer! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-19 14:17 Message: Logged In: YES user_id=21627 The patch applies to version 2.13 of HyperArch.py, just as the patch header says. It was current for the mailman CVS at the time of its creation. It has been applied to the mailman CVS by now (as 2.14), so it is now useless. Feel free to back-port it to mailman 2.0.8 if you want. ---------------------------------------------------------------------- Comment By: Karsten Dambekalns (k-fish) Date: 2002-06-19 12:55 Message: Logged In: YES user_id=105527 I tried to apply this patch to mailman 2.0.8 and 2.0.9, and both times the patch didn't apply cleanly. In fact 6 out of 10 hunks failed here. Any hints on that? For which version was the patch created? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-02 00:40 Message: Logged In: YES user_id=21627 The second version of this patch expects and ignores LookupError from unicode(), and it decodes the subjects from the next and previous articles. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=510415&group_i…

1 0

problems with iso... encoding
by Fil 27 Jun '02

27 Jun '02

Hi Mailman-devs, I don"t understand why, since I upgraded Mailman to the current cvs 2.1b2+ (from a former 2.1b1) the accents encoding are all dead ; it seems that a creepy ^M (higlighted below) puts it wrong. It might be because I had diffidulty installing the email package (_compat22.py would yield a complaint : I had to do a 'cp _compat21.py _compat22.py to install)... I have Python 2.1.2 ----- Forwarded message from Fil <fil(a)rezo.net> ----- Subject: [Test] =?iso-8859-1?Q?probl=E8mes_d'accents_je_te?=^M =?iso-8859-1?B?c3RlIDog4CDpIOcg6A==?= ? ----- End forwarded message ----- Help will be appreciated.

1 0

[ mailman-Bugs-574240 ] web ui confirm button placement
by noreply＠sourceforge.net 26 Jun '02

26 Jun '02

Bugs item #574240, was opened at 2002-06-26 14:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=574240&group_i… Category: (un)subscribing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Christopher Kolar (ckolar) Assigned to: Nobody/Anonymous (nobody) Summary: web ui confirm button placement Initial Comment: Hi. Running 2.1b2 I just did a test subscription via email. When I clicked on the link to confirm the confirmation page came up properly. I am a bit bugged by the UI though. The Confirm button was way off to the left -- right under all of the user informaiton on the screen was the "dismiss and discard" button (or whatever it was labeled). After checking the info on the screen I very nearly hit the button because I could not see the real confirm burron and the discard button, being placed right under the info, seemed to instinctively be a good place for a confirm button. I would change the UI to at least get both of them in the center. Cheers, --chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=574240&group_i…

1 0

Fix for the last error I reported
by Bob Puff＠NLE 26 Jun '02

26 Jun '02

Hey Gang, I finally found a fix for the last show-stopper I reported: > File "/home/mm21/mailman/pythonlib/email/_compat22.py", line 41, in body_line_iterator > if isinstance(payload, StringTypes): > TypeError: isinstance() arg 2 must be a class or type It seems that while: > admin(22824): [----- Python Information -----] > admin(22824): sys.version = 2.2b1 (#2, Oct 29 2001, 16:07:36) > [GCC 2.95.3 19991030 (prerelease)] I copied _compat21.py over top _compat22.py, and it now works. So, it seems that _compat22.py isn't really compatible with the 2.2 beta 1 release of Python. Bob

1 0

Error in Deliverer.py, b2
by Tollef Fog Heen 26 Jun '02

26 Jun '02

line 110 in Deliverer.py should read: 'password' : self.getMemberPassword(user), and not access the password hash directly. This is needed in order to use other MemberAdaptors. -- Tollef Fog Heen ,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-

1 0

Making the anonymize option really anonymize
by Kristoffer Gleditsch 25 Jun '02

25 Jun '02

Hi, We have a setup where we need the anonymizing feature "Hide the sender of a message ..." to actually anonymize the messages going through the list. Both in the archive and in the mails it sent out, it left headers that (normally) make it pretty easy to track the sender. This patch against Mailman/Handlers/Cleanse.py from version 2.0.11 should remove most of those. It strips the recieved-headers, generates a new Message-ID and sets the envelope-from address to the list admin. Regards, -- Kristoffer.

1 0

[ mailman-Feature Requests-573394 ] separate auto-disable and "nomail" flags
by noreply＠sourceforge.net 25 Jun '02

25 Jun '02

Feature Requests item #573394, was opened at 2002-06-25 01:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=573394&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Stein (gstein) Assigned to: Nobody/Anonymous (nobody) Summary: separate auto-disable and "nomail" flags Initial Comment: Currently, Mailman will disable email to accounts (say, because they bounced too many times) by setting the "nomail" option. *However*, that option is also used by users. As a result, I have no way to determine which subscriptions are old/invalid, and which correspond to actual users. It would be nice to record disabling as a separate field... say, as the date the account was disabled. Then, I could periodically find all accounts which were disabled more than a year ago and simply delete them. Thus, users who temporarily disable mail delivery will not accidentally have their subscriptions purged :-) ---------------------------------------------------------------------- Comment By: Jesús Cea Avión (jcea) Date: 2002-06-25 12:32 Message: Logged In: YES user_id=97460 Good. You've read my mind :-). This feature is a "must have" :-). ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2002-06-25 03:50 Message: Logged In: YES user_id=6501 Yes, that is a definite improvement. Note that logs get rotated, so you might not know "when" a particular transition occurred. For my particular problem, I'd be happy with the current 2.1 behavior, and would be even happier with the change date added, too. thx! ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-06-25 01:52 Message: Logged In: YES user_id=10725 MM 2.1 adds a "reason" enumeration to the disabled flag, so at least the 'bounce' vs. 'user' or 'administrator' distinction is obvious. The date of the event is also available in the log files. Not that that's as useful as what you suggest, but it's partway there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=573394&group_i…

1 0