From noreply at sourceforge.net Thu Jun 1 06:39:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 May 2006 21:39:42 -0700 Subject: [ mailman-Bugs-1498213 ] bad email sanitisation issue Message-ID: Bugs item #1498213, was opened at 2006-05-31 06:26 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1498213&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: kangoo (kangbooboo) Assigned to: Nobody/Anonymous (nobody) Summary: bad email sanitisation issue Initial Comment: hi, we're using 2.1.5 and when someone added an email address with quotes (") we got errors a bit everywhere and mails not getting sent ^^ I looked into changelog up to 2.1.8 which is current stable and this looks closely to bug #1030228, but different character. I would suggest adding the quote character to the filter (ascii 042) Or better, rewritte the filter but the reverse way. only allow [a-zA-Z0-9\-\_\.\+] for email addresses ? (i made this up from memory but email addresses cannot contain much more ? maybe im saying something stupid here) ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-05-31 21:39 Message: Logged In: YES user_id=1123998 First of all, local-parts of email addresses are allowed to be quoted per RFC2821 sec 4.1.2, but more importantly, can you be more specific as to 1) the form of the address with " that caused problems 2) how it was added if not via the web interface 3) what specific errors/problems result I note that I am able to add an address of the form Real Name <"user at example.com"> via Mass Subscribe, and the resultant address receives mail just as if it weren't quoted. ---------------------------------------------------------------------- Comment By: kangoo (kangbooboo) Date: 2006-05-31 06:36 Message: Logged In: YES user_id=671502 i forgot to say this is done when you're not using the web interface to input the email+name (else name or mail with quotes gets rejected as unknown) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1498213&group_id=103 From noreply at sourceforge.net Thu Jun 1 06:52:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 May 2006 21:52:03 -0700 Subject: [ mailman-Bugs-1498290 ] Footer sometimes appended to last line of message Message-ID: Bugs item #1498290, was opened at 2006-05-31 08:24 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1498290&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Kamens (jikamens) Assigned to: Nobody/Anonymous (nobody) Summary: Footer sometimes appended to last line of message Initial Comment: If someone submits a multipart/alternative message, and the text part doesn't have a trailing newline, then the footer is started at the end of the last line in the text part, rather than starting on a new line. I think the code that appends the footer should be fixed so that if the text message doesn't end with a newline, one is added before the footer is appended. Thanks. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-05-31 21:52 Message: Logged In: YES user_id=1123998 Can you be more specific as to how this occurs. In particular, if the message after content filtering is still multipart/alternative, the footer won't be added to the text/plain alternative. In this case, the message will be wrapped in a multipart/mixed outer part and the footer appended as a separate text/plain part. Footers are only added to a text/plain part when the entire message (perhaps after content filtering) is a single text/plain part. Note, I am not trying to say this is not a problem or it shouldn't be fixed. I'm just trying to understand how it occurs. Also, I'm not trying to say that this is a solution, but as a workaround, you could always add a blank line to the beginning of the footer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1498290&group_id=103 From noreply at sourceforge.net Thu Jun 1 07:08:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 May 2006 22:08:48 -0700 Subject: [ mailman-Bugs-1498290 ] Footer sometimes appended to last line of message Message-ID: Bugs item #1498290, was opened at 2006-05-31 11:24 Message generated for change (Comment added) made by jikamens You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1498290&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Kamens (jikamens) Assigned to: Nobody/Anonymous (nobody) Summary: Footer sometimes appended to last line of message Initial Comment: If someone submits a multipart/alternative message, and the text part doesn't have a trailing newline, then the footer is started at the end of the last line in the text part, rather than starting on a new line. I think the code that appends the footer should be fixed so that if the text message doesn't end with a newline, one is added before the footer is appended. Thanks. ---------------------------------------------------------------------- >Comment By: Jonathan Kamens (jikamens) Date: 2006-06-01 01:08 Message: Logged In: YES user_id=274776 You're right, what's happening is the footer is getting attached as a separate text/plain element. The problem is that the text/plain part of the multipart/alternative is missing a trailing newline, so my mail client is displaying the footer right after the last line of the text/plain part (since my mail client displays the text/plain part rather than the text/html). Perhaps my mail client is at fault; it's hard to say. I doubt it would be appropriate for MailMan to go mucking with the original text/plain part. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-06-01 00:52 Message: Logged In: YES user_id=1123998 Can you be more specific as to how this occurs. In particular, if the message after content filtering is still multipart/alternative, the footer won't be added to the text/plain alternative. In this case, the message will be wrapped in a multipart/mixed outer part and the footer appended as a separate text/plain part. Footers are only added to a text/plain part when the entire message (perhaps after content filtering) is a single text/plain part. Note, I am not trying to say this is not a problem or it shouldn't be fixed. I'm just trying to understand how it occurs. Also, I'm not trying to say that this is a solution, but as a workaround, you could always add a blank line to the beginning of the footer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1498290&group_id=103 From noreply at sourceforge.net Thu Jun 1 07:15:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 May 2006 22:15:16 -0700 Subject: [ mailman-Bugs-1498290 ] Footer sometimes appended to last line of message Message-ID: Bugs item #1498290, was opened at 2006-05-31 11:24 Message generated for change (Comment added) made by jikamens You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1498290&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Kamens (jikamens) Assigned to: Nobody/Anonymous (nobody) Summary: Footer sometimes appended to last line of message Initial Comment: If someone submits a multipart/alternative message, and the text part doesn't have a trailing newline, then the footer is started at the end of the last line in the text part, rather than starting on a new line. I think the code that appends the footer should be fixed so that if the text message doesn't end with a newline, one is added before the footer is appended. Thanks. ---------------------------------------------------------------------- >Comment By: Jonathan Kamens (jikamens) Date: 2006-06-01 01:15 Message: Logged In: YES user_id=274776 FYI, Use VM 7.19 inside GNU emacs. I just managed to fix this easily inside VM, so I suppose we can call it a VM bug rather than a MailMan bug and close this ticket. ---------------------------------------------------------------------- Comment By: Jonathan Kamens (jikamens) Date: 2006-06-01 01:08 Message: Logged In: YES user_id=274776 You're right, what's happening is the footer is getting attached as a separate text/plain element. The problem is that the text/plain part of the multipart/alternative is missing a trailing newline, so my mail client is displaying the footer right after the last line of the text/plain part (since my mail client displays the text/plain part rather than the text/html). Perhaps my mail client is at fault; it's hard to say. I doubt it would be appropriate for MailMan to go mucking with the original text/plain part. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-06-01 00:52 Message: Logged In: YES user_id=1123998 Can you be more specific as to how this occurs. In particular, if the message after content filtering is still multipart/alternative, the footer won't be added to the text/plain alternative. In this case, the message will be wrapped in a multipart/mixed outer part and the footer appended as a separate text/plain part. Footers are only added to a text/plain part when the entire message (perhaps after content filtering) is a single text/plain part. Note, I am not trying to say this is not a problem or it shouldn't be fixed. I'm just trying to understand how it occurs. Also, I'm not trying to say that this is a solution, but as a workaround, you could always add a blank line to the beginning of the footer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1498290&group_id=103 From noreply at sourceforge.net Thu Jun 1 15:57:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 06:57:41 -0700 Subject: [ mailman-Bugs-1498290 ] Footer sometimes appended to last line of message Message-ID: Bugs item #1498290, was opened at 2006-05-31 08:24 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1498290&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) >Status: Closed Resolution: None Priority: 5 Submitted By: Jonathan Kamens (jikamens) Assigned to: Nobody/Anonymous (nobody) Summary: Footer sometimes appended to last line of message Initial Comment: If someone submits a multipart/alternative message, and the text part doesn't have a trailing newline, then the footer is started at the end of the last line in the text part, rather than starting on a new line. I think the code that appends the footer should be fixed so that if the text message doesn't end with a newline, one is added before the footer is appended. Thanks. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-01 06:57 Message: Logged In: YES user_id=1123998 Closing per submitter. ---------------------------------------------------------------------- Comment By: Jonathan Kamens (jikamens) Date: 2006-05-31 22:15 Message: Logged In: YES user_id=274776 FYI, Use VM 7.19 inside GNU emacs. I just managed to fix this easily inside VM, so I suppose we can call it a VM bug rather than a MailMan bug and close this ticket. ---------------------------------------------------------------------- Comment By: Jonathan Kamens (jikamens) Date: 2006-05-31 22:08 Message: Logged In: YES user_id=274776 You're right, what's happening is the footer is getting attached as a separate text/plain element. The problem is that the text/plain part of the multipart/alternative is missing a trailing newline, so my mail client is displaying the footer right after the last line of the text/plain part (since my mail client displays the text/plain part rather than the text/html). Perhaps my mail client is at fault; it's hard to say. I doubt it would be appropriate for MailMan to go mucking with the original text/plain part. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-05-31 21:52 Message: Logged In: YES user_id=1123998 Can you be more specific as to how this occurs. In particular, if the message after content filtering is still multipart/alternative, the footer won't be added to the text/plain alternative. In this case, the message will be wrapped in a multipart/mixed outer part and the footer appended as a separate text/plain part. Footers are only added to a text/plain part when the entire message (perhaps after content filtering) is a single text/plain part. Note, I am not trying to say this is not a problem or it shouldn't be fixed. I'm just trying to understand how it occurs. Also, I'm not trying to say that this is a solution, but as a workaround, you could always add a blank line to the beginning of the footer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1498290&group_id=103 From noreply at sourceforge.net Thu Jun 1 21:04:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 12:04:26 -0700 Subject: [ mailman-Feature Requests-1499055 ] send encrypted passwords Message-ID: Feature Requests item #1499055, was opened at 2006-06-01 21:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1499055&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: zwiskle (zwiskle) Assigned to: Nobody/Anonymous (nobody) Summary: send encrypted passwords Initial Comment: just a idea: If a user creates a account, the system could lookup on a pgp-keyserver if a pub-key exists. the passwords could then (optional, as per user-request) sent as pgp/gnupg-encrypted email. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1499055&group_id=103 From noreply at sourceforge.net Thu Jun 1 21:08:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 12:08:45 -0700 Subject: [ mailman-Feature Requests-1499062 ] support opendid / yadis Message-ID: Feature Requests item #1499062, was opened at 2006-06-01 21:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1499062&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: zwiskle (zwiskle) Assigned to: Nobody/Anonymous (nobody) Summary: support opendid / yadis Initial Comment: yadis is a framework which privides access to other services like openid, lid, inames... ( these do similar-things like microsoft passport - but are "nicer" ( open-source, can have my own servern ... ) ) having e.g. a common open-id account would help to keep the number of site-username/passwords lower. http://yadis.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1499062&group_id=103 From noreply at sourceforge.net Thu Jun 1 21:11:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 12:11:24 -0700 Subject: [ mailman-Feature Requests-1474203 ] A junk Mail button would be great Message-ID: Feature Requests item #1474203, was opened at 2006-04-21 15:23 Message generated for change (Comment added) made by zwiskle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1474203&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Narishkup (mikekatz) Assigned to: Nobody/Anonymous (nobody) Summary: A junk Mail button would be great Initial Comment: I would love a junk mail button in the administrators review of defered messages section. That button would with one click delete the message and put the senders domain on the rejected domain list. Currently it is a 4 click proccess to put each ban people but domains are even harder to restrict. This should be a button in addition to the existing choices so that less drastic action could also be taken. Thanks so mucch fo a great product. ---------------------------------------------------------------------- Comment By: zwiskle (zwiskle) Date: 2006-06-01 21:11 Message: Logged In: YES user_id=1130747 maybe there could be some more logic in behind - e.g. feed this spam-mail to spamassassin-learn. ( or forward this to a spam-learn email-account ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1474203&group_id=103 From noreply at sourceforge.net Sat Jun 3 00:42:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Jun 2006 15:42:30 -0700 Subject: [ mailman-Feature Requests-1497366 ] Differentiate between subscribers/others for held messages Message-ID: Feature Requests item #1497366, was opened at 2006-05-30 01:03 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1497366&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonas Maebe (jmaebe) Assigned to: Nobody/Anonymous (nobody) Summary: Differentiate between subscribers/others for held messages Initial Comment: I've turned off notifications about messages held for approval, since virtually all of them are spam with forged from-addresses and I don't want to inundate random people with such notifications. However, every now and then the reason is that a subscriber tried to send too big an attachment, or because a mail triggered my html regexp in the privacy filters. Therefore I would like to propose an option to only send "Message held for approval" messages to subscribers, but not to anyone else. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-02 15:42 Message: Logged In: YES user_id=1123998 Moved to Feature Requests because that's what it is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1497366&group_id=103 From noreply at sourceforge.net Sat Jun 3 01:57:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Jun 2006 16:57:35 -0700 Subject: [ mailman-Patches-762130 ] web interface for editing archives Message-ID: Patches item #762130, was opened at 2003-06-27 18:05 Message generated for change (Comment added) made by aaboyd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=762130&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Adriane Boyd (aaboyd) Assigned to: Nobody/Anonymous (nobody) Summary: web interface for editing archives Initial Comment: This patch makes it possible for list administrators to edit their list archives through a web interface linked into the admin interface. A new cgi script called editarch allows administrators to browse by month and delete messages from the archives. The messages are immediately deleted from the mbox file, but because of the overhead in reprocessing archives, the archives aren't redone on-the-fly. Instead, a file is kept with a running list of recently edited archives and a nightly cron job does the reprocessing. The file location is configurable in mm_cfg. (Note: since it has to read through the mbox file message by message, pages will load slowly for lists with large archives.) In the mailman 2.1.2 source directory: patch -p1 < editarch-2.1.2-0.1.patch ---------------------------------------------------------------------- >Comment By: Adriane Boyd (aaboyd) Date: 2006-06-02 19:57 Message: Logged In: YES user_id=696276 Updated patch to work with 2.1.8: fixed problems with mailbox.py and updated to patch cleanly against 2.1.8. ---------------------------------------------------------------------- Comment By: Adriane Boyd (aaboyd) Date: 2003-08-11 17:25 Message: Logged In: YES user_id=696276 Updated so that the permissions on the mbox file are set properly after editing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=762130&group_id=103 From noreply at sourceforge.net Sun Jun 4 17:46:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 08:46:24 -0700 Subject: [ mailman-Patches-1482427 ] Migration 2.0.5 to 2.1.5 bug + fix Message-ID: Patches item #1482427, was opened at 2006-05-05 04:57 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1482427&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: configure/install Group: Mailman 2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Markus Neteler (mneteler) Assigned to: Nobody/Anonymous (nobody) Summary: Migration 2.0.5 to 2.1.5 bug + fix Initial Comment: Hi, we are happy mailman users for many years and finally made the update yesterday. But there was a detail which needs to be fixed: ## from 2.0.5 to ## mailman-2.1.5.1-34.rhel4.2 # modify in file /usr/lib/mailman/bin/dumpdb # BAW: this probably doesn't work if there are mixed types of .db # files (i.e. some marshals, some bdbs). d = DumperSwitchboard().read(filename) to import marshal ... # BAW: this probably doesn't work if there are mixed types of .db # files (i.e. some marshals, some bdbs). fp = open(filename) d = marshal.load(fp) fp.close() Only then it will work (we were seeking for two hours to figure out... :-) This would solve this problem as well apparently: http://mail.python.org/pipermail/mailman-users/2005-February/042654.html Kind regards Markus Neteler http://grass.itc.it ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-04 08:46 Message: Logged In: YES user_id=1123998 Fixed in subversion trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1482427&group_id=103 From noreply at sourceforge.net Mon Jun 5 17:56:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 08:56:08 -0700 Subject: [ mailman-Feature Requests-1501086 ] Make confirm links in email optional Message-ID: Feature Requests item #1501086, was opened at 2006-06-05 08:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1501086&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: John W. Baxter (jwbaxter) Assigned to: Nobody/Anonymous (nobody) Summary: Make confirm links in email optional Initial Comment: An organization which attempts to train its members or employees (or otherwise-involved critters) never to click on links in email messages should not itself send out messages containing links with suggestions to click them. In today's malware world, such an organization is acting sensibly. In the present mailman, the goal can be achieved by adjusting message templates. It would seem better--despite the desire not to have options proliferate endlessly--to provide an option in the list configuration to disable such links. (That would probably not include disabling the RFC list headers, which can already be disabled separately.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1501086&group_id=103 From noreply at sourceforge.net Wed Jun 7 05:22:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 20:22:42 -0700 Subject: [ mailman-Patches-762130 ] web interface for editing archives Message-ID: Patches item #762130, was opened at 2003-06-28 06:05 Message generated for change (Comment added) made by pabs3 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=762130&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Adriane Boyd (aaboyd) Assigned to: Nobody/Anonymous (nobody) Summary: web interface for editing archives Initial Comment: This patch makes it possible for list administrators to edit their list archives through a web interface linked into the admin interface. A new cgi script called editarch allows administrators to browse by month and delete messages from the archives. The messages are immediately deleted from the mbox file, but because of the overhead in reprocessing archives, the archives aren't redone on-the-fly. Instead, a file is kept with a running list of recently edited archives and a nightly cron job does the reprocessing. The file location is configurable in mm_cfg. (Note: since it has to read through the mbox file message by message, pages will load slowly for lists with large archives.) In the mailman 2.1.2 source directory: patch -p1 < editarch-2.1.2-0.1.patch ---------------------------------------------------------------------- Comment By: Paul Wise (pabs3) Date: 2006-06-07 11:22 Message: Logged In: YES user_id=35028 How does this handle the changing of pipermail URLs when you delete messages? ---------------------------------------------------------------------- Comment By: Adriane Boyd (aaboyd) Date: 2006-06-03 07:57 Message: Logged In: YES user_id=696276 Updated patch to work with 2.1.8: fixed problems with mailbox.py and updated to patch cleanly against 2.1.8. ---------------------------------------------------------------------- Comment By: Adriane Boyd (aaboyd) Date: 2003-08-12 05:25 Message: Logged In: YES user_id=696276 Updated so that the permissions on the mbox file are set properly after editing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=762130&group_id=103 From noreply at sourceforge.net Wed Jun 7 21:06:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Jun 2006 12:06:02 -0700 Subject: [ mailman-Patches-1502441 ] newlist mail without prompt Message-ID: Patches item #1502441, was opened at 2006-06-07 14:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1502441&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line scripts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick Bogen (pdbogen) Assigned to: Nobody/Anonymous (nobody) Summary: newlist mail without prompt Initial Comment: bin/newlist should have an option to send a mail to the administrator without requiring the user to ansewr a prompt. The attached patch adds a '-a/--automate' option to accomplish this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1502441&group_id=103 From noreply at sourceforge.net Thu Jun 8 05:45:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Jun 2006 20:45:16 -0700 Subject: [ mailman-Patches-762130 ] web interface for editing archives Message-ID: Patches item #762130, was opened at 2003-06-27 18:05 Message generated for change (Comment added) made by aaboyd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=762130&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Adriane Boyd (aaboyd) Assigned to: Nobody/Anonymous (nobody) Summary: web interface for editing archives Initial Comment: This patch makes it possible for list administrators to edit their list archives through a web interface linked into the admin interface. A new cgi script called editarch allows administrators to browse by month and delete messages from the archives. The messages are immediately deleted from the mbox file, but because of the overhead in reprocessing archives, the archives aren't redone on-the-fly. Instead, a file is kept with a running list of recently edited archives and a nightly cron job does the reprocessing. The file location is configurable in mm_cfg. (Note: since it has to read through the mbox file message by message, pages will load slowly for lists with large archives.) In the mailman 2.1.2 source directory: patch -p1 < editarch-2.1.2-0.1.patch ---------------------------------------------------------------------- >Comment By: Adriane Boyd (aaboyd) Date: 2006-06-07 23:45 Message: Logged In: YES user_id=696276 The nightly cron script just runs "bin/arch --wipe" for any list with edited archives, so the pipermail URLs for particular messages in a list archive may change. Because of the way pipermail works, there's no easy solution that keeps the URLs the same and removes messages from mailman's mbox archives. (There might be a solution that keeps URLs the same if unwanted messages were replaced with empty placeholder messages instead, but I'm not sure you'd want empty messages cluttering up your archives, either.) Even if you haven't edited the mbox file, badly formed date stamps will also cause your pipermail URLs to change if you ever run "bin/arch --wipe" because messages with bad dates get thrown into the current month. ---------------------------------------------------------------------- Comment By: Paul Wise (pabs3) Date: 2006-06-06 23:22 Message: Logged In: YES user_id=35028 How does this handle the changing of pipermail URLs when you delete messages? ---------------------------------------------------------------------- Comment By: Adriane Boyd (aaboyd) Date: 2006-06-02 19:57 Message: Logged In: YES user_id=696276 Updated patch to work with 2.1.8: fixed problems with mailbox.py and updated to patch cleanly against 2.1.8. ---------------------------------------------------------------------- Comment By: Adriane Boyd (aaboyd) Date: 2003-08-11 17:25 Message: Logged In: YES user_id=696276 Updated so that the permissions on the mbox file are set properly after editing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=762130&group_id=103 From noreply at sourceforge.net Thu Jun 8 17:34:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 08:34:20 -0700 Subject: [ mailman-Patches-1502441 ] newlist mail without prompt Message-ID: Patches item #1502441, was opened at 2006-06-07 12:06 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1502441&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line scripts Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Patrick Bogen (pdbogen) >Assigned to: Mark Sapiro (msapiro) Summary: newlist mail without prompt Initial Comment: bin/newlist should have an option to send a mail to the administrator without requiring the user to ansewr a prompt. The attached patch adds a '-a/--automate' option to accomplish this. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-08 08:34 Message: Logged In: YES user_id=1123998 Applied (somewhat differently because of new framework for bin/ and cron/ commands) to Subversion trunk for 2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1502441&group_id=103 From noreply at sourceforge.net Sat Jun 10 21:47:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 12:47:03 -0700 Subject: [ mailman-Feature Requests-567096 ] list_members script export Name+Address Message-ID: Feature Requests item #567096, was opened at 2002-06-10 15:13 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=567096&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Rodolfo Pilas (alkalino) Assigned to: Nobody/Anonymous (nobody) Summary: list_members script export Name+Address Initial Comment: I uses MM 2.1b2+ (from CVS this month -June 2002) The mass subscription (web) option enables me to put one user address form each line with this format: Name Surname <name at address.com> and works ok. However the $PREFIX/bin/list_members script do not export with this format, it list name at address.com only. Please, add to list_members a complete user data exportation. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-10 12:47 Message: Logged In: YES user_id=1123998 Actually implemented in 2.1b4 (Oct 2002) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=567096&group_id=103 From noreply at sourceforge.net Sun Jun 11 04:32:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 19:32:34 -0700 Subject: [ mailman-Bugs-1504204 ] re-confirm memberships Message-ID: Bugs item #1504204, was opened at 2006-06-10 19:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504204&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: bounce detection Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daevid Vincent (daevid) Assigned to: Nobody/Anonymous (nobody) Summary: re-confirm memberships Initial Comment: I have a suspicion that some of my lists' mails are not getting to their destinations. This could be that some people used their job email and no longer work there, could be that they are on AOL or hotmail (which seem to just silently discard), or could be just people that joined up and now 'junk mail or filter' the list because they're either to stupid or lazy to properly unsubscribe. Bottom line is that I'm paying per emails sent (via my quota on DynDNS) and I want to unsubscribe these dead members. It would be great if I could push a button in the web GUI (or run some command on the CLI) and mailman would reset every members status to 'unconfirmed' (or whatever it is), mail them a link to click (with some crazy code in it like when you join a list), and then mark the responders as 'confirmed'. Then after some period of time, say a week or so, I could then go into the GUI, click some link and see a list of all 'unconfirmed' people with the option to unsubscribe them all (without sending an email obviously, since the address is bogus). Extra points if I can schedule this task to occur every month, every six months, once a year, etc... (probably some 'day' interval would be sufficient here). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504204&group_id=103 From noreply at sourceforge.net Sun Jun 11 05:45:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 20:45:46 -0700 Subject: [ mailman-Bugs-1504204 ] re-confirm memberships Message-ID: Bugs item #1504204, was opened at 2006-06-10 19:32 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504204&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: bounce detection Group: None >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Daevid Vincent (daevid) Assigned to: Nobody/Anonymous (nobody) Summary: re-confirm memberships Initial Comment: I have a suspicion that some of my lists' mails are not getting to their destinations. This could be that some people used their job email and no longer work there, could be that they are on AOL or hotmail (which seem to just silently discard), or could be just people that joined up and now 'junk mail or filter' the list because they're either to stupid or lazy to properly unsubscribe. Bottom line is that I'm paying per emails sent (via my quota on DynDNS) and I want to unsubscribe these dead members. It would be great if I could push a button in the web GUI (or run some command on the CLI) and mailman would reset every members status to 'unconfirmed' (or whatever it is), mail them a link to click (with some crazy code in it like when you join a list), and then mark the responders as 'confirmed'. Then after some period of time, say a week or so, I could then go into the GUI, click some link and see a list of all 'unconfirmed' people with the option to unsubscribe them all (without sending an email obviously, since the address is bogus). Extra points if I can schedule this task to occur every month, every six months, once a year, etc... (probably some 'day' interval would be sufficient here). ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-10 20:45 Message: Logged In: YES user_id=1123998 This is really an RFE, not a bug and it duplicates RFE 1495305. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504204&group_id=103 From noreply at sourceforge.net Sun Jun 11 19:55:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 10:55:56 -0700 Subject: [ mailman-Feature Requests-782436 ] members per page on admin page Message-ID: Feature Requests item #782436, was opened at 2003-08-03 12:32 Message generated for change (Comment added) made by jwbaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=782436&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: JC Dill (jcdill) Assigned to: Nobody/Anonymous (nobody) Summary: members per page on admin page Initial Comment: Put a radio button option on the membership page to allow list owners to change the number of members returned on each page. I suggest that the options include: 25 per page 50 per page 100 per page 200 per page 500 per page all subscribers on one page (use with caution if you have a big list!) ---------------------------------------------------------------------- Comment By: John W. Baxter (jwbaxter) Date: 2006-06-11 10:55 Message: Logged In: YES user_id=664644 This seems like a quite reasonable proposal. Is the intent to return to the old method, where the pages (except last) were all full and there was on each page an index of links giving the first (first and last) address on each other page? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=782436&group_id=103 From noreply at sourceforge.net Mon Jun 12 04:19:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 19:19:44 -0700 Subject: [ mailman-Bugs-1504546 ] Subscription log mixes up names and email addresses Message-ID: Bugs item #1504546, was opened at 2006-06-12 04:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504546&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Moritz Naumann (mnaumann) Assigned to: Nobody/Anonymous (nobody) Summary: Subscription log mixes up names and email addresses Initial Comment: On /var/log/mailman/subscribe successful subscriptions are logged like this: Jun 11 18:40:58 2006 (30403) mylistname: new (digest) "henry23 at hotmail.com" , via web confirmation The intended way to log them is probably rather this: Jun 11 18:40:58 2006 (30403) mylistname: new (digest) "Henry" , via web confirmation Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504546&group_id=103 From noreply at sourceforge.net Mon Jun 12 04:35:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 19:35:24 -0700 Subject: [ mailman-Bugs-1504546 ] Subscription log mixes up names and email addresses Message-ID: Bugs item #1504546, was opened at 2006-06-11 19:19 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504546&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Moritz Naumann (mnaumann) Assigned to: Nobody/Anonymous (nobody) Summary: Subscription log mixes up names and email addresses Initial Comment: On /var/log/mailman/subscribe successful subscriptions are logged like this: Jun 11 18:40:58 2006 (30403) mylistname: new (digest) "henry23 at hotmail.com" , via web confirmation The intended way to log them is probably rather this: Jun 11 18:40:58 2006 (30403) mylistname: new (digest) "Henry" , via web confirmation Thanks! ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-11 19:35 Message: Logged In: YES user_id=1123998 What Mailman version is this? This error was fixed in 2.1.8 unless there is some other way it can occur. See http://svn.sourceforge.net/viewcvs.cgi/mailman/tags/Release_2_1_8/mailman/Mailman/MailList.py?r1=7783&r2=7818 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504546&group_id=103 From noreply at sourceforge.net Mon Jun 12 04:42:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 19:42:23 -0700 Subject: [ mailman-Bugs-1504546 ] Subscription log mixes up names and email addresses Message-ID: Bugs item #1504546, was opened at 2006-06-12 04:19 Message generated for change (Settings changed) made by mnaumann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504546&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: 2.1 (stable) >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Moritz Naumann (mnaumann) Assigned to: Nobody/Anonymous (nobody) Summary: Subscription log mixes up names and email addresses Initial Comment: On /var/log/mailman/subscribe successful subscriptions are logged like this: Jun 11 18:40:58 2006 (30403) mylistname: new (digest) "henry23 at hotmail.com" , via web confirmation The intended way to log them is probably rather this: Jun 11 18:40:58 2006 (30403) mylistname: new (digest) "Henry" , via web confirmation Thanks! ---------------------------------------------------------------------- >Comment By: Moritz Naumann (mnaumann) Date: 2006-06-12 04:42 Message: Logged In: YES user_id=407680 This indeed refers to 2.1.7. And the patch you refer to should fix this. Thanks for the quick reply. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-06-12 04:35 Message: Logged In: YES user_id=1123998 What Mailman version is this? This error was fixed in 2.1.8 unless there is some other way it can occur. See http://svn.sourceforge.net/viewcvs.cgi/mailman/tags/Release_2_1_8/mailman/Mailman/MailList.py?r1=7783&r2=7818 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504546&group_id=103 From noreply at sourceforge.net Tue Jun 13 08:54:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Jun 2006 23:54:33 -0700 Subject: [ mailman-Bugs-1495122 ] Mailman strips format=flowed from Content-Type header Message-ID: Bugs item #1495122, was opened at 2006-05-25 21:24 Message generated for change (Comment added) made by radiantskies You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1495122&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Bart Jacobs (radiantskies) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman strips format=flowed from Content-Type header Initial Comment: It seems that Mailman strips the format=flowed argument from the Content-Type: text/plain header when delivering incoming e-mails to subscribers. ---------------------------------------------------------------------- >Comment By: Bart Jacobs (radiantskies) Date: 2006-06-13 08:54 Message: Logged In: YES user_id=924185 I've browsed the mailman source code a bit and I found some suspicious code in /trunk/mailman/Mailman/Handlers/Decorate.py. If the list admin specifies a header or footer to be added to outgoing messages, then the content-type header is zapped and then regenerated from just the charset info, i.e. the format=flowed parameter is lost. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1495122&group_id=103 From noreply at sourceforge.net Tue Jun 13 18:34:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 09:34:49 -0700 Subject: [ mailman-Bugs-1495122 ] Mailman strips format=flowed from Content-Type header Message-ID: Bugs item #1495122, was opened at 2006-05-25 12:24 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1495122&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Bart Jacobs (radiantskies) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman strips format=flowed from Content-Type header Initial Comment: It seems that Mailman strips the format=flowed argument from the Content-Type: text/plain header when delivering incoming e-mails to subscribers. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-13 09:34 Message: Logged In: YES user_id=1123998 I think you have found the cause. Scrubber also does the same thing when flattening the message, but now we have a difficult decision. If we want to 'fix' Decorate, we now are faced with a situation where we may be adding a 'format=fixed' header and/or footer to a 'format=flowed' message body. This potential incompatability may require us to 'wrap' the message and add the header/footer as separate parts in this case. This will undoubtedly raise additional complaints. In the case of Scrubber, this may lead us to scrub the actual message body part - not a good thing. I may be over-reacting here. It may turn out that it is OK to render the header/footer/scrubber messages as 'format=flowed'. Although I can contrive a footer for example (by putting trailing spaces on intermediate lines) that will be munged by rendering as 'format=flowed', this may not be a problem in practice, and Decorate could always be made to strip the spaces. There are also potentially issues with stripping of leading spaces because of the assumption that they are 'stuffed'. I don't know how big an issue this is in practice. Note, if we do preserve 'format=' we also need to preserve 'delsp='. ---------------------------------------------------------------------- Comment By: Bart Jacobs (radiantskies) Date: 2006-06-12 23:54 Message: Logged In: YES user_id=924185 I've browsed the mailman source code a bit and I found some suspicious code in /trunk/mailman/Mailman/Handlers/Decorate.py. If the list admin specifies a header or footer to be added to outgoing messages, then the content-type header is zapped and then regenerated from just the charset info, i.e. the format=flowed parameter is lost. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1495122&group_id=103 From noreply at sourceforge.net Wed Jun 14 23:07:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 14:07:42 -0700 Subject: [ mailman-Bugs-1506338 ] cannot post to list Message-ID: Bugs item #1506338, was opened at 2006-06-14 17:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1506338&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: mdbiker (mdbiker) Assigned to: Nobody/Anonymous (nobody) Summary: cannot post to list Initial Comment: i am an administrator (but i didn't install it nor do i have access to the server) of an announcement only mailing list. despite having 3 addresses listed as administrator and moderator, we have only been able to use one address to post. that was ok till last week when we were subject to a spoofing attack appearing to come from that address. i removed that address, having forgotten about the problem in posting from the others. now i cannot post tothe list at all even though i returned the removed address. for each i get back a "this is an announcement list - send your email to xxxx for posting and now even xxxx cannot post. so the bug is that even though listed as admin/mod i cannot post. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1506338&group_id=103 From noreply at sourceforge.net Thu Jun 15 02:25:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 17:25:59 -0700 Subject: [ mailman-Bugs-1506338 ] cannot post to list Message-ID: Bugs item #1506338, was opened at 2006-06-14 14:07 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1506338&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: mdbiker (mdbiker) Assigned to: Nobody/Anonymous (nobody) Summary: cannot post to list Initial Comment: i am an administrator (but i didn't install it nor do i have access to the server) of an announcement only mailing list. despite having 3 addresses listed as administrator and moderator, we have only been able to use one address to post. that was ok till last week when we were subject to a spoofing attack appearing to come from that address. i removed that address, having forgotten about the problem in posting from the others. now i cannot post tothe list at all even though i returned the removed address. for each i get back a "this is an announcement list - send your email to xxxx for posting and now even xxxx cannot post. so the bug is that even though listed as admin/mod i cannot post. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-14 17:25 Message: Logged In: YES user_id=1123998 First, I see you've already posted this to mailman-users at python.org which is probably a more appropriate place to go first. Second, this is not a bug. The addresses in the 'owner' and 'moderator' attributes are ONLY addresses to which owner and moderator notices are mailed, and in the case of owner, listed in the 'run by' footer at the bottom of web pages. These addresses have no other function. If they are not also members, they will not receive list posts. If posting is restricted to members or unmoderated members, they will not be allowed to post unless they are (unmoderated) members or listed in accept_these_nonmembers. It seems from your description that the default for your list is that new members are moderated and moderated members can't post. You deleted the one unmoderated member so no one could post and when you added xxxx back, xxxx was moderated by default. You could turn off moderation for those members you want to post, but a more 'spoof proof' method is use of an Approved: header as discussed in FAQs http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.011.htp and http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.034.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1506338&group_id=103 From noreply at sourceforge.net Fri Jun 16 14:14:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 05:14:58 -0700 Subject: [ mailman-Bugs-1507248 ] no delivery to lists "wrong" footer characters Message-ID: Bugs item #1507248, was opened at 2006-06-16 14:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Ulrik Haugen (ulrik_haugen) Assigned to: Nobody/Anonymous (nobody) Summary: no delivery to lists "wrong" footer characters Initial Comment: Mailman 2.1.8: I recently had a problem with list administrators changing the footer to something containing characters that do not fit the default language for the list. (Actually it was the result of an upgrade but it can be reproduced more easily this way.) This resulted in letters to these lists going to the archive but not beeing distributed to list members. After some investigation i discovered that they were instead getting sent to the shunt directory with the following error message in logs/error: Jun 15 16:40:26 2006 (11718) Uncaught runner exception: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) Traceback (most recent call last): File "/service/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/service/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/service/mailman/Mailman/Queue/OutgoingRunner.py", line 73, in _dispose self._func(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/SMTPDirect.py", line 132, in process Decorate.process(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/Decorate.py", line 99, in process ufooter = unicode(footer, lcset) UnicodeError: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) SHUNTING: 1150382425.6505611+4f10f0ef8067c96952336a07919d018adc6a9979 I think this is a very bad idea as it results in the list administrator complaining to me as site administrator about letters not being delivered instead of (for instance) the list members complaing to the list administrator about unreadable characters in the footer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_id=103 From noreply at sourceforge.net Fri Jun 16 18:03:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 09:03:22 -0700 Subject: [ mailman-Bugs-1507248 ] no delivery to lists "wrong" footer characters Message-ID: Bugs item #1507248, was opened at 2006-06-16 05:14 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Ulrik Haugen (ulrik_haugen) Assigned to: Nobody/Anonymous (nobody) Summary: no delivery to lists "wrong" footer characters Initial Comment: Mailman 2.1.8: I recently had a problem with list administrators changing the footer to something containing characters that do not fit the default language for the list. (Actually it was the result of an upgrade but it can be reproduced more easily this way.) This resulted in letters to these lists going to the archive but not beeing distributed to list members. After some investigation i discovered that they were instead getting sent to the shunt directory with the following error message in logs/error: Jun 15 16:40:26 2006 (11718) Uncaught runner exception: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) Traceback (most recent call last): File "/service/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/service/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/service/mailman/Mailman/Queue/OutgoingRunner.py", line 73, in _dispose self._func(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/SMTPDirect.py", line 132, in process Decorate.process(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/Decorate.py", line 99, in process ufooter = unicode(footer, lcset) UnicodeError: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) SHUNTING: 1150382425.6505611+4f10f0ef8067c96952336a07919d018adc6a9979 I think this is a very bad idea as it results in the list administrator complaining to me as site administrator about letters not being delivered instead of (for instance) the list members complaing to the list administrator about unreadable characters in the footer. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-16 09:03 Message: Logged In: YES user_id=1123998 I think you are correct. I'm not sure about the fix though. Current code in Decorate.py is (sorry for wrapped lines): # TK: Try to keep the message plain by converting the header/ # footer/oldpayload into unicode and encode with mcset/lcset. # Try to decode qp/base64 also. uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) try: oldpayload = unicode(msg.get_payload(decode=True), mcset) frontsep = endsep = u'' I see two approaches to fix this. The first is to change uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) to uheader = unicode(header, lcset, 'ignore') ufooter = unicode(footer, lcset, 'ignore') This will cause the rogue characters to be ignored. The second approach is to move the uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) try: inside the try as try: uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) The result of this will be to add the header and/or footer in separate MIME parts in this case. I also thought of using 'replace' instead of 'ignore' in the first approach, but this will likely result in a UnicodeError in encode() later on and ultimately have the same result as the second approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_id=103 From noreply at sourceforge.net Sat Jun 17 04:00:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 19:00:15 -0700 Subject: [ mailman-Patches-1507615 ] Updated courier-to-mailman.py Message-ID: Patches item #1507615, was opened at 2006-06-17 02:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1507615&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Knowles (shub) Assigned to: Nobody/Anonymous (nobody) Summary: Updated courier-to-mailman.py Initial Comment: Submitted to me by Lindsay Haisley , who took the qmail-to-mailman.py script in the contrib/ directory, and modified it to suit for use with the Courier MTA. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1507615&group_id=103 From noreply at sourceforge.net Sun Jun 18 00:49:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jun 2006 15:49:12 -0700 Subject: [ mailman-Bugs-1507248 ] no delivery to lists "wrong" footer characters Message-ID: Bugs item #1507248, was opened at 2006-06-16 14:14 Message generated for change (Comment added) made by ulrik_haugen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Ulrik Haugen (ulrik_haugen) Assigned to: Nobody/Anonymous (nobody) Summary: no delivery to lists "wrong" footer characters Initial Comment: Mailman 2.1.8: I recently had a problem with list administrators changing the footer to something containing characters that do not fit the default language for the list. (Actually it was the result of an upgrade but it can be reproduced more easily this way.) This resulted in letters to these lists going to the archive but not beeing distributed to list members. After some investigation i discovered that they were instead getting sent to the shunt directory with the following error message in logs/error: Jun 15 16:40:26 2006 (11718) Uncaught runner exception: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) Traceback (most recent call last): File "/service/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/service/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/service/mailman/Mailman/Queue/OutgoingRunner.py", line 73, in _dispose self._func(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/SMTPDirect.py", line 132, in process Decorate.process(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/Decorate.py", line 99, in process ufooter = unicode(footer, lcset) UnicodeError: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) SHUNTING: 1150382425.6505611+4f10f0ef8067c96952336a07919d018adc6a9979 I think this is a very bad idea as it results in the list administrator complaining to me as site administrator about letters not being delivered instead of (for instance) the list members complaing to the list administrator about unreadable characters in the footer. ---------------------------------------------------------------------- >Comment By: Ulrik Haugen (ulrik_haugen) Date: 2006-06-18 00:49 Message: Logged In: YES user_id=636029 If I understand correctly the solutions you outline are: 1) Have mailman strip the characters outside the list character set from any header/footer and "attach" the remainder to the message as before. 2) Attach the header/footer as separate parts if they contain characters outside the list character set but mark these parts as beeing encoded with the list character set. If so, I'd certainly prefer the first approach, stripping the header/footer over delivering incorrectly marked messages. One other option might be to skip the header/footer entirely if it can't be attached correctly. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-06-16 18:03 Message: Logged In: YES user_id=1123998 I think you are correct. I'm not sure about the fix though. Current code in Decorate.py is (sorry for wrapped lines): # TK: Try to keep the message plain by converting the header/ # footer/oldpayload into unicode and encode with mcset/lcset. # Try to decode qp/base64 also. uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) try: oldpayload = unicode(msg.get_payload(decode=True), mcset) frontsep = endsep = u'' I see two approaches to fix this. The first is to change uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) to uheader = unicode(header, lcset, 'ignore') ufooter = unicode(footer, lcset, 'ignore') This will cause the rogue characters to be ignored. The second approach is to move the uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) try: inside the try as try: uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) The result of this will be to add the header and/or footer in separate MIME parts in this case. I also thought of using 'replace' instead of 'ignore' in the first approach, but this will likely result in a UnicodeError in encode() later on and ultimately have the same result as the second approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_id=103 From noreply at sourceforge.net Mon Jun 19 22:47:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 13:47:11 -0700 Subject: [ mailman-Feature Requests-874329 ] Next/Previous Month links in archives Message-ID: Feature Requests item #874329, was opened at 2004-01-10 03:45 Message generated for change (Comment added) made by mamandel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=874329&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nathan Gray (n8gray) Assigned to: Nobody/Anonymous (nobody) Summary: Next/Previous Month links in archives Initial Comment: Mailman has really improved my life with its wonderful archive generation, but there's one oversight in the interface. There should be "Next Month" and "Previous Month" links in the thread/date view of the archives. It's pretty annoying to have to manually type the month name in the URL or go back to the list-info, then to the archive list, then to the month in question. ---------------------------------------------------------------------- Comment By: Mark A. Mandel (mamandel) Date: 2006-06-19 16:47 Message: Logged In: YES user_id=915526 I second the motion. I'm not a sysadmin, I'm a researcher, and perforce a research administrator. At times I have been maintaining 6-8 lists for different but related groups, and searching back and forth through several of those lists for a discussion that took place something like a year ago is just maddening, simply because there's no way to jump to the next archive set (next or previous month). You have to go up several pages -- BACK won't do it, because the previous page was the previous post that you read. And then you've got a page full of these lines -- October 2003: [ Thread ] [ Subject ] [ Author ] [ Date ] [ Gzip'd Text 19 KB ] -- and if you happen to have been skipping around before zeroing in on the year or the quarter you want, there's no visual clue even to where you were. That's the kind of thing you ought to be able to keep in mind easily, but late in a tiring day it's just one more pain. Your alternative, of course, is to go into the address line and replace "2003-October" with "2003-November". This is probably a little more galling for me than for most list administrators because I have difficulty with long terms of typing and mousing, and prefer to do as much as I can with speech recognition. [This text prepared with Dragon NaturallySpeaking.] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=874329&group_id=103 From noreply at sourceforge.net Thu Jun 22 17:18:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 08:18:53 -0700 Subject: [ mailman-Bugs-1054944 ] Default templates set bgcolors Message-ID: Bugs item #1054944, was opened at 2004-10-27 01:58 Message generated for change (Comment added) made by hramrach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1054944&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: MJ Ray (slef) Assigned to: Nobody/Anonymous (nobody) Summary: Default templates set bgcolors Initial Comment: Many of the templates for the CGI and for the archives set background colours but do not set text colours. This leads to readers who don't use dark-on-light default colours getting very hard-to-read pages. Mailman is not following Web Content Accessibility Guideline 2.2 I attach a patch which fixes templates/en in a minimal way. I hope that's OK. If not, please direct me. ---------------------------------------------------------------------- Comment By: Michal Suchanek (hramrach) Date: 2006-06-22 17:18 Message: Logged In: YES user_id=404997 What's the status of this? There are many broken installations of MailMan out there where the subscription page is unreadable. It is still broken in 2.1.7 (I doubt the site admins actively break this). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1054944&group_id=103 From noreply at sourceforge.net Fri Jun 23 12:28:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 03:28:41 -0700 Subject: [ mailman-Bugs-1511226 ] Bug in cs translation Message-ID: Bugs item #1511226, was opened at 2006-06-23 12:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1511226&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Ladislav Vaiz (ziav) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in cs translation Initial Comment: Please apply patch sent as attachment. It fixed month name bug in Czech transation. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1511226&group_id=103 From noreply at sourceforge.net Fri Jun 23 22:18:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 13:18:14 -0700 Subject: [ mailman-Bugs-1507248 ] no delivery to lists "wrong" footer characters Message-ID: Bugs item #1507248, was opened at 2006-06-16 05:14 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ulrik Haugen (ulrik_haugen) >Assigned to: Mark Sapiro (msapiro) Summary: no delivery to lists "wrong" footer characters Initial Comment: Mailman 2.1.8: I recently had a problem with list administrators changing the footer to something containing characters that do not fit the default language for the list. (Actually it was the result of an upgrade but it can be reproduced more easily this way.) This resulted in letters to these lists going to the archive but not beeing distributed to list members. After some investigation i discovered that they were instead getting sent to the shunt directory with the following error message in logs/error: Jun 15 16:40:26 2006 (11718) Uncaught runner exception: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) Traceback (most recent call last): File "/service/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/service/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/service/mailman/Mailman/Queue/OutgoingRunner.py", line 73, in _dispose self._func(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/SMTPDirect.py", line 132, in process Decorate.process(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/Decorate.py", line 99, in process ufooter = unicode(footer, lcset) UnicodeError: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) SHUNTING: 1150382425.6505611+4f10f0ef8067c96952336a07919d018adc6a9979 I think this is a very bad idea as it results in the list administrator complaining to me as site administrator about letters not being delivered instead of (for instance) the list members complaing to the list administrator about unreadable characters in the footer. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-23 13:18 Message: Logged In: YES user_id=1123998 This is now fixed in Subversion both in the trunk and the Release_2_1-maint branch. The fix strips (ignores) header/footer characters outside the character set of the list's language. ---------------------------------------------------------------------- Comment By: Ulrik Haugen (ulrik_haugen) Date: 2006-06-17 15:49 Message: Logged In: YES user_id=636029 If I understand correctly the solutions you outline are: 1) Have mailman strip the characters outside the list character set from any header/footer and "attach" the remainder to the message as before. 2) Attach the header/footer as separate parts if they contain characters outside the list character set but mark these parts as beeing encoded with the list character set. If so, I'd certainly prefer the first approach, stripping the header/footer over delivering incorrectly marked messages. One other option might be to skip the header/footer entirely if it can't be attached correctly. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-06-16 09:03 Message: Logged In: YES user_id=1123998 I think you are correct. I'm not sure about the fix though. Current code in Decorate.py is (sorry for wrapped lines): # TK: Try to keep the message plain by converting the header/ # footer/oldpayload into unicode and encode with mcset/lcset. # Try to decode qp/base64 also. uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) try: oldpayload = unicode(msg.get_payload(decode=True), mcset) frontsep = endsep = u'' I see two approaches to fix this. The first is to change uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) to uheader = unicode(header, lcset, 'ignore') ufooter = unicode(footer, lcset, 'ignore') This will cause the rogue characters to be ignored. The second approach is to move the uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) try: inside the try as try: uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) The result of this will be to add the header and/or footer in separate MIME parts in this case. I also thought of using 'replace' instead of 'ignore' in the first approach, but this will likely result in a UnicodeError in encode() later on and ultimately have the same result as the second approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_id=103 From noreply at sourceforge.net Fri Jun 30 11:00:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 02:00:31 -0700 Subject: [ mailman-Patches-871062 ] A MemberAdaptor for LDAP-based membership Message-ID: Patches item #871062, was opened at 2004-01-05 18:09 Message generated for change (Comment added) made by viktu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=871062&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: K. A. Krueger (fubarobfusco) Assigned to: Nobody/Anonymous (nobody) Summary: A MemberAdaptor for LDAP-based membership Initial Comment: This is a module, LDAPMemberships, which extends MemberAdaptor to support membership lists based on a search in an enterprise LDAP directory. With this module, you can make mailing lists which, rather than having a list of member addresses stored in the list, query your LDAP server for member addresses whenever necessary. For instance, if you wish to have a mailing list of all the Vice Presidents in your company, you can express this as an LDAP search: "(title=Vice President*)" and create a mailing list which performs this search and delivers mail to the resulting user accounts when a message is sent to it. This way, rather than manually adding new Vice Presidents to the mailing list, you can simply have Human Resources update the LDAP records, and the change will immediately take effect for the mailing list. Mailman lists with LDAP-based membership can still have moderators, list policies, and the other usual features of Mailman lists. There are a few missing features; notably: 1. There is no bounce processing. 2. There are no per-user preferences. 3. The Web interface still allows you to try setting user preferences, but if you do you will get a stack thrown at you. (Only the "readable" interface of MemberAdaptor is implemented.) 4. The LDAP settings of a list (e.g. LDAP server and search string) are only administrable by editing its "extend.py" file, not over the Web. 5. There is no digest mode. To use this module, you must have the "ldap" Python module installed (aka "python-ldap"). Then just put LDAPMemberships.py in the "Mailman" directory (~mailman/Mailman), create a new list, and write an "extend.py" file in the list directory like so: ##### from Mailman.LDAPMemberships import LDAPMemberships def extend(list): ldap = LDAPMemberships(list) ldap.ldapsearch = "(title=Vice President*)" # members search string ldap.ldapserver = "ldap.example.net" # your enterprise LDAP server ldap.ldapbasedn = "dc=Example dc=net" # your LDAP base DN ldap.ldapbinddn = '' # a bind DN which can read people's 'mail' field ldap.ldappasswd = '' # the password for the bind DN list._memberadaptor = ldap ##### This module has been tested at my site and is in production on a Mailman 2.1.2 installation. ---------------------------------------------------------------------- Comment By: Viktu Pons (viktu) Date: 2006-06-30 11:00 Message: Logged In: YES user_id=1530492 Hi all, I'm having troubles with this memberadaptor, which I can't resolve as I have no idea of python :( The fact is that sometimes it works, sometimes not. If the query returns few values (this is 50,60) it works fine, but when I have to select a huge amount of addresses (say 3000) it gives up giving errors such "Can't contact LDAP server". Then it puts the message in the shunt folder, and sometimes unshunting several times it sends the email, and sometimes you lose it forever and can't find where it went. Any ideas? Anyone having the same problem? Thanks a lot! ---------------------------------------------------------------------- Comment By: K. A. Krueger (fubarobfusco) Date: 2005-02-01 18:02 Message: Logged In: YES user_id=944208 I've just uploaded version 0.4 of LDAPMemberships.py. This includes the patch by the_olo to support multiple values in 'mail', and also fixes a bug reported by Mark Sapiro involving importing defaults from the wrong module. ---------------------------------------------------------------------- Comment By: martin whinnery (mawhin) Date: 2004-08-25 17:39 Message: Logged In: YES user_id=90418 I've hacked your work about to get it to handle lists based on group membership instead. You may find it worthwhile. http://webserver.offal.homelinux.org/LDAPMemberAdaptor/V3.0/LDAPMemberAdaptor/ This version's nasty, but you'll get the idea. Wanna roll it into yours? Mart ---------------------------------------------------------------------- Comment By: Aleksander Adamowski (the_olo) Date: 2004-04-05 15:47 Message: Logged In: YES user_id=244001 I suggest this patch to allow senders use any source address they might have set in LDAP (the 'mail' attribute can have multiple values!) --- LDAPMemberships.py.orig 2004-04-01 12:31:54.000000000 +0200 +++ LDAPMemberships.py 2004-04-05 15:40:03.000000000 +0200 @@ -115,7 +115,9 @@ # mail is unique mail = attrs['mail'][0].strip() self.__members.append(mail) - self.__member_map[mail] = mail + # mail can have multiple values + for secondarymail in attrs['mail']: + self.__member_map[secondarymail.strip()] = mail if attrs.has_key('mailalternateaddress'): malts = attrs['mailalternateaddress'] for malt in malts: ---------------------------------------------------------------------- Comment By: K. A. Krueger (fubarobfusco) Date: 2004-03-31 05:59 Message: Logged In: YES user_id=944208 Well, Mailman does a lot more than just keep track of who's subscribed -- for instance, restricted posters, list moderation, archiving. LDAPMemberships is not meant to be useful for Internet mailing lists with people signing up for them, but rather for institutional or enterprise lists. These have a lot of the same requirements (moderation etc.) as Internet lists, but don't need subscription/unsubscription -- since employees are usually required to be on them. My workplace is using this (well, actually a later version than the one I've uploaded here) as a replacement for an LDAP mailing-list feature in Netscape SuiteSpot now that we have migrated away from that system. We -also- use LDAP-based aliases (in Postfix, not Sendmail, actually) -- but for some things we need the moderation and other facilities that Mailman has. For instance, we have an announcements list that goes to all regular employees. A simple alias would allow anyone to send stuff to it, and certain senior scientists would love to send big PDFs to everyone. A Mailman list with LDAPMemberships can have sender restrictions so that only our IT Director and our mail systems admin can approve posts to it. Archiving is also quite useful for announcements lists. ---------------------------------------------------------------------- Comment By: Chris Drumgoole (cdrum) Date: 2004-03-31 05:38 Message: Logged In: YES user_id=429400 why use this when you can just use Sendmail's LDAP -> Alias functions? No need for a mailing list program like mailman.. right? ---------------------------------------------------------------------- Comment By: K. A. Krueger (fubarobfusco) Date: 2004-01-26 21:35 Message: Logged In: YES user_id=944208 Yet another new version (0.3) of LDAPMemberships.py. This one fixes some ambiguities with LDAP record handling, particularly for users with multiple "cn" values, and those who send mail as their "mailalternateaddress" field address rather than their "mail" field. If anyone is actually using this, please email me and let me know :) ---------------------------------------------------------------------- Comment By: K. A. Krueger (fubarobfusco) Date: 2004-01-20 17:53 Message: Logged In: YES user_id=944208 I've uploaded a new version (0.2) of LDAPMemberships.py. This one is some ungodly number of times faster, as it does not do redundant LDAP queries in a single load. ---------------------------------------------------------------------- Comment By: K. A. Krueger (fubarobfusco) Date: 2004-01-05 18:18 Message: Logged In: YES user_id=944208 Er. SF ate the indentation on my "extend.py" example in the patch description. All of the lines after "def extend(list):" are meant to be indented once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=871062&group_id=103