Mailman 3 November 2006 - Mailman-coders

[ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers
by SourceForge.net Nov. 29, 2006

Nov. 29, 2006

Bugs item #1605144, was opened at 2006-11-29 10: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=1605144&group_… 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 Private: No Submitted By: David Woodhouse (dwmw2) Assigned to: Nobody/Anonymous (nobody) Summary: mailman corrupts RFC2047-encoded headers Initial Comment: Given an input like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup,=20fix=20ECC=20on=20reading=20empty=20flash?= Mailman appears to emit mail like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup, =20fix=20ECC=20on=20reading=20empty=20flash?= The input was RFC2047-compliant. The output isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&group_…

1 0

[ mailman-Bugs-1603400 ] difficult to discard spam postings via e-mail
by SourceForge.net Nov. 26, 2006

Nov. 26, 2006

Bugs item #1603400, was opened at 2006-11-27 01:09 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=1603400&group_… 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 Private: No Submitted By: Paul Pogonyshev (doublep) Assigned to: Nobody/Anonymous (nobody) Summary: difficult to discard spam postings via e-mail Initial Comment: In notifications about spam-posting to my project's mailing list, this is written: If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. Natural reflex is to hit R (reply) to reply to the whole message. This doesn't work... This text comes in an encapsulated message and it is difficult to reply to an encapsulated message (at least in KMail: you need to right-click "encapsulated message" text, choose view, then reply, and then close the view window.) It would be simpler if just replying to the message you get worked for discarding spam, without all the additional moves. (I posted this to Savane first, but they redirected me here.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1603400&group_…

1 0

[ mailman-Bugs-209499 ] Security hole: passwords mailed in clear
by SourceForge.net Nov. 26, 2006

Nov. 26, 2006

Bugs item #209499, was opened at 2000-07-14 15:26 Message generated for change (Comment added) made by bburkhart You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=209499&group_i… 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: Wont Fix Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Security hole: passwords mailed in clear Initial Comment: I recently signed up on a SourceForge mailing list. The software mailed a confirmation notice to my mailbox, with the password in clear in the message. This is a basic security hole. I reported this as a SourceForge bug, and they said "Contact the gnu-mailman project." In my opinion, passwords should never be mailed in clear, especially not to the e-mail address with which they are associated. Please consider changing this. ---------------------------------------------------------------------- Comment By: Benjamin Bl�mchen (bburkhart) Date: 2006-11-27 08:23 Message: Logged In: YES user_id=597317 Originator: NO Hello everyone, to me, mailing passwords in clear text is never acceptable. In some setups. one never knows who else is looking at the mail. The lack of biological RAM in layer 8 is also not an excuse. There are better ways of dealing with the password remembering problem. Anyway, mailman is now out of question and also uninstalled from my machine. Cheers Benjamin ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2000-07-24 18:31 Message: It's OK with me if you want to close this report; in my opinion, the Resolution should say "Wont fix". ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2000-07-17 21:43 Message: The Mailman password is in no way a secure password. Mailman is intended for a wide variety of users, most of which are unable to remember even the simplest password ;) The Mailman password is not used as an authentication method, but more as a *confirmation* method. You'll get a password reminder every month or so (if the list admin and site admin enabled that) and the only thing you use the password for are for unsubscribing, changing your options and viewing the private archive (if any.) In future versions of Mailman it might be possible to use external passwords for mailinglist subscribers, but currently the infrastructure for that is missing. It's on the TODO list, in any case :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=209499&group_i…

1 0

[ mailman-Bugs-1601302 ] no confirm if not necessary
by SourceForge.net Nov. 22, 2006

Nov. 22, 2006

Bugs item #1601302, was opened at 2006-11-22 13:23 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=1601302&group_… 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 Private: No Submitted By: Full Decent (fulldecent) Assigned to: Nobody/Anonymous (nobody) Summary: no confirm if not necessary Initial Comment: If I enter my email address and password, then click unsubscribe, that should be the end of it - no email confirmation required. A confirmation should only be required when I do not have my password. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1601302&group_…

1 0

[ mailman-Bugs-1598087 ] Error mail may be accumulated in qfiles
by SourceForge.net Nov. 17, 2006

Nov. 17, 2006

Bugs item #1598087, was opened at 2006-11-16 15:55 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1598087&group_… 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 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Error mail may be accumulated in qfiles Initial Comment: Mailman/Queue/Runner.py is called by other runners and resposible for dequeueing from one queue and enqueue into another after processing. In _oneloop() function it shunts error messages during processing but leaves them in the original queue directory by noting 'Ignoring ...' message in the error log. These left errorneous messages are never treated again and may be accumulated and slow down the queue processing. These messages should be shunted also. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-11-16 21:36 Message: Logged In: YES user_id=1123998 Originator: NO If I understand the issue correctly, the problem is that the .bak file is left in the original queue after the parse error. This is not a recoverable error as explained in the code comment, thus I don't think the proper action is to shunt the message. Rather, I think the proper action is to continue to log the event and just remove the .bak file. Not removing the .bak file was an oversight in the original backup implementation. My suggested patch is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1598087&group_…

1 0

[ mailman-Bugs-1598087 ] Error mail may be accumulated in qfiles
by SourceForge.net Nov. 16, 2006

Nov. 16, 2006

Bugs item #1598087, was opened at 2006-11-16 23:55 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=1598087&group_… 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 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Error mail may be accumulated in qfiles Initial Comment: Mailman/Queue/Runner.py is called by other runners and resposible for dequeueing from one queue and enqueue into another after processing. In _oneloop() function it shunts error messages during processing but leaves them in the original queue directory by noting 'Ignoring ...' message in the error log. These left errorneous messages are never treated again and may be accumulated and slow down the queue processing. These messages should be shunted also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1598087&group_…

1 0

[ mailman-Feature Requests-673265 ] Post confirmation + moderation
by SourceForge.net Nov. 13, 2006

Nov. 13, 2006

Feature Requests item #673265, was opened at 2003-01-24 02:39 Message generated for change (Comment added) made by watha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&group_i… 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 Private: No Submitted By: Samuel Tardieu (samtardieu) Assigned to: Nobody/Anonymous (nobody) Summary: Post confirmation + moderation Initial Comment: The following scheme (implemented by me for Sympa as a scenario some time ago) leads to a spam-free mailing-list with almost no work from the moderator. When a mail arrive and should be held for any reason (sender not in subscriber list, list not in to: or cc:, too many recipients), ask the alleged sender to confirm its post then hold it for moderation when the sender confirms its intention to post. This way, spam (whose confirmation request will almost never be answered) is not presented to the moderators, while mail sent by humans will. It would be great to have this feature in mailman. ---------------------------------------------------------------------- Comment By: James Andrewartha (watha) Date: 2006-11-13 10:48 Message: Logged In: YES user_id=460267 http://viewmtn.angrygoats.net/revision/diff/dfedaca2816739f4f052d21247f6877… has an implementation for this, although there's a few other features mixed into the diff as well. ---------------------------------------------------------------------- Comment By: Lucas Nussbaum (lnu) Date: 2006-11-11 18:52 Message: Logged In: YES user_id=527142 Also, this could be implemented in a greylist-like way: the sender would have to confirm his first post, and then, its mails would get auto-accepted for a few hours/days. ---------------------------------------------------------------------- Comment By: Lucas Nussbaum (lnu) Date: 2006-11-11 18:34 Message: Logged In: YES user_id=527142 Hi, This feature would really be great to have in mailman. Additionnally, a web-based confirmation interface could be added, with an image-based confirmation, to prevent robots from auto-confirming their posts. Is it planned ? I'm a bit concerned by the fact that this feature request was posted more than 3 years ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&group_i…

1 0

[ mailman-Feature Requests-673265 ] Post confirmation + moderation
by SourceForge.net Nov. 11, 2006

Nov. 11, 2006

Feature Requests item #673265, was opened at 2003-01-23 18:39 Message generated for change (Comment added) made by lnu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&group_i… 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 Private: No Submitted By: Samuel Tardieu (samtardieu) Assigned to: Nobody/Anonymous (nobody) Summary: Post confirmation + moderation Initial Comment: The following scheme (implemented by me for Sympa as a scenario some time ago) leads to a spam-free mailing-list with almost no work from the moderator. When a mail arrive and should be held for any reason (sender not in subscriber list, list not in to: or cc:, too many recipients), ask the alleged sender to confirm its post then hold it for moderation when the sender confirms its intention to post. This way, spam (whose confirmation request will almost never be answered) is not presented to the moderators, while mail sent by humans will. It would be great to have this feature in mailman. ---------------------------------------------------------------------- Comment By: Lucas Nussbaum (lnu) Date: 2006-11-11 10:52 Message: Logged In: YES user_id=527142 Also, this could be implemented in a greylist-like way: the sender would have to confirm his first post, and then, its mails would get auto-accepted for a few hours/days. ---------------------------------------------------------------------- Comment By: Lucas Nussbaum (lnu) Date: 2006-11-11 10:34 Message: Logged In: YES user_id=527142 Hi, This feature would really be great to have in mailman. Additionnally, a web-based confirmation interface could be added, with an image-based confirmation, to prevent robots from auto-confirming their posts. Is it planned ? I'm a bit concerned by the fact that this feature request was posted more than 3 years ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&group_i…

1 0

[ mailman-Feature Requests-673265 ] Post confirmation + moderation
by SourceForge.net Nov. 11, 2006

Nov. 11, 2006

Feature Requests item #673265, was opened at 2003-01-23 18:39 Message generated for change (Comment added) made by lnu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&group_i… 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 Private: No Submitted By: Samuel Tardieu (samtardieu) Assigned to: Nobody/Anonymous (nobody) Summary: Post confirmation + moderation Initial Comment: The following scheme (implemented by me for Sympa as a scenario some time ago) leads to a spam-free mailing-list with almost no work from the moderator. When a mail arrive and should be held for any reason (sender not in subscriber list, list not in to: or cc:, too many recipients), ask the alleged sender to confirm its post then hold it for moderation when the sender confirms its intention to post. This way, spam (whose confirmation request will almost never be answered) is not presented to the moderators, while mail sent by humans will. It would be great to have this feature in mailman. ---------------------------------------------------------------------- Comment By: Lucas Nussbaum (lnu) Date: 2006-11-11 10:34 Message: Logged In: YES user_id=527142 Hi, This feature would really be great to have in mailman. Additionnally, a web-based confirmation interface could be added, with an image-based confirmation, to prevent robots from auto-confirming their posts. Is it planned ? I'm a bit concerned by the fact that this feature request was posted more than 3 years ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&group_i…

1 0

[ mailman-Patches-1589056 ] list only lists from the requested domain
by SourceForge.net Nov. 2, 2006

Nov. 2, 2006

Patches item #1589056, was opened at 2006-11-01 23:30 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=1589056&group_… 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 Private: No Submitted By: The Anarcat (anarcat) Assigned to: Nobody/Anonymous (nobody) Summary: list only lists from the requested domain Initial Comment: In Mailman 2.1, the listinfo page lists all pages belonging to the current vhost. Or not exactly. It lists all lists that have the current vhost in their web_page_url. Which is wrong, because if I have a list like list(a)sub.example.com and visit http://example.com/mailman/listinfo, it *will* be listed. I would expect it to be listed only if I visit http://sub.example.com/mailman/listinfo. This one-line patch fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1589056&group_…

1 0