Mailman 3 May 2006 - Mailman-coders

[ mailman-Bugs-1240368 ] header problems
by SourceForge.net May 14, 2006

May 14, 2006

Bugs item #1240368, was opened at 2005-07-18 19:06 Message generated for change (Comment added) made by girla You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1240368&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 Submitted By: Sepphoria (sepphoria) Assigned to: Nobody/Anonymous (nobody) Summary: header problems Initial Comment: If a header and a footer are added to mail sent to regular list members under Non-Digest options, using Outlook as the email client for sending email, Outlook delivers the email with the header as a .txt attachment, and the body of the email as an .html file attachment. The footer is normal. Using a different email client (Netscape) for sending email, Outlook delivers the email with the header and footer in a .txt attachment. The text of the email is normal (in the body of the email). This is the case for version 2.1.5. ---------------------------------------------------------------------- Comment By: Girla (girla) Date: 2006-05-14 17:07 Message: Logged In: YES user_id=1210276 Have the same problem, in case when mail has file(s) attachment(s): then header going as normal mail body, then in msg attachment mail body, then file(s) attachment, and footer in msg attachment. Using The Bat!, Mozilla Thunderbird, variuos webmails. Version MailMan 2.1.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1240368&group_…

1 0

[ mailman-Feature Requests-1486877 ] administrator vs. moderator settings
by SourceForge.net May 11, 2006

May 11, 2006

Feature Requests item #1486877, was opened at 2006-05-11 17:01 Message generated for change (Comment added) made by jimpop You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1486877&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 Submitted By: karl berry (kberry) Assigned to: Nobody/Anonymous (nobody) Summary: administrator vs. moderator settings Initial Comment: Werner Lemberg recently sent a message to mailman-users about separately defining notifications for administrators vs. moderators. While wholeheartedly supporting Werner's general proposal (I currently filter hundreds of useless notifications every day), I'd like to suggest a slightly different variation -- perhaps it's easier to implement too: Have an interface which allows specifying, for any given email address, 1) whether it is a moderator or an administrator 2) whether it should get the daily mails 3) whether it should get the immediate notifications For an interface, I can imagine a screen similar to the current membership management screen (though with many fewer columns). I think this is preferable because on some lists I list myself as a moderator, on others as an administrator, for various reasons. But I never want to get the immediate notifications, regardless of whether I am an admin or a moderator. It occurs to me that the split into "admin" and "moderator" is perhaps misleading in the first place, since the main difference (AFAIK) is whether the given address is listed on the publicly viewable HTML pages. Maybe they should just all be "administrative email address", and whether it is listed or not on the public page is a fourth specification. Other related options I can think of could perhaps be specified the same way, on a per-administrative-email basis: whether it gets (un)subscribes, and whether it gets disabled/deleted bounce notifications. (There is no use in sending anything but the immediate notifications to our robot helper.) Whether it's possible to specify defaults for all these things is not important to me. Having hardwired defaults would be fine. Hope this makes some kind of sense and can be considered for a future release ... Thanks, karl ---------------------------------------------------------------------- Comment By: Jim Popovitch (jimpop) Date: 2006-05-11 18:18 Message: Logged In: YES user_id=3142 I agree that changes to the Owner/Moderator interfaces need some thought. My thought is this: Just eliminate the concept of separate interface settings for defining list Owners and Moderators and replace it by adding Mod and Owner fields to normal users just like NoMail. This way Owners could easily rotate Moderators, and both could easily change their email delivery options from NoMail to Digest to Normal. Tuff luck if all the Owners set NoMail at the same time, however some might want that capability. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1486877&group_…

1 0

[ mailman-Feature Requests-1486877 ] administrator vs. moderator settings
by SourceForge.net May 11, 2006

May 11, 2006

Feature Requests item #1486877, was opened at 2006-05-11 21:01 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=1486877&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 Submitted By: karl berry (kberry) Assigned to: Nobody/Anonymous (nobody) Summary: administrator vs. moderator settings Initial Comment: Werner Lemberg recently sent a message to mailman-users about separately defining notifications for administrators vs. moderators. While wholeheartedly supporting Werner's general proposal (I currently filter hundreds of useless notifications every day), I'd like to suggest a slightly different variation -- perhaps it's easier to implement too: Have an interface which allows specifying, for any given email address, 1) whether it is a moderator or an administrator 2) whether it should get the daily mails 3) whether it should get the immediate notifications For an interface, I can imagine a screen similar to the current membership management screen (though with many fewer columns). I think this is preferable because on some lists I list myself as a moderator, on others as an administrator, for various reasons. But I never want to get the immediate notifications, regardless of whether I am an admin or a moderator. It occurs to me that the split into "admin" and "moderator" is perhaps misleading in the first place, since the main difference (AFAIK) is whether the given address is listed on the publicly viewable HTML pages. Maybe they should just all be "administrative email address", and whether it is listed or not on the public page is a fourth specification. Other related options I can think of could perhaps be specified the same way, on a per-administrative-email basis: whether it gets (un)subscribes, and whether it gets disabled/deleted bounce notifications. (There is no use in sending anything but the immediate notifications to our robot helper.) Whether it's possible to specify defaults for all these things is not important to me. Having hardwired defaults would be fine. Hope this makes some kind of sense and can be considered for a future release ... Thanks, karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1486877&group_…

1 0

[ mailman-Bugs-1085651 ] Broken PGP/MIME signature of messages with attachments
by SourceForge.net May 11, 2006

May 11, 2006

Bugs item #1085651, was opened at 2004-12-15 09:54 Message generated for change (Comment added) made by proffe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1085651&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 Submitted By: Etienne M. Gagnon (egagnon) Assigned to: Nobody/Anonymous (nobody) Summary: Broken PGP/MIME signature of messages with attachments Initial Comment: Hi, When I send a PGP/MIME signed message *with* attachments (in addition to the PGP signature) to a Mailman-based mailing list, Firefox/Enigmail fails to verify the signature of the message forwarded by mailman. I have uploaded an example message with a broken signature as attachment to this bug. You can also see how Mailman's automatic archives don't even handle such messages correctly by looking at how it archived that message at: http://sablecc.org/lists/sablecc-user/2004-December/000159.html I've looked in the bugs database and found that a somewhat related problem was reported a while ago, but note that the current bug is different. The original bug was about PGP/MIME signed messages without attachments that were handled incorrectly by Enigmail. This one is about messages with attachments, and it is likely that the bug is Mailman's, at least accroding to the reply I got in: http://bugzilla.mozdev.org/show_bug.cgi?id=8466 Thanks for your help (and for the magnificient software)! Etienne ---------------------------------------------------------------------- Comment By: Magnus Holmgren (proffe) Date: 2006-05-11 12:02 Message: Logged In: YES user_id=669310 This is a duplicate of bug #815297. ---------------------------------------------------------------------- Comment By: Bas Wijnen (shevek) Date: 2005-03-20 14:51 Message: Logged In: YES user_id=42389 That function does indeed not conserve whitespace. E-mail doesn't say whitespace in headers (or even the message) must be preserved, so strictly speaking it's not a bug. However, it is a missing feature, and I think python is the place to implement it, not mailman. The point is that signed e-mails with attachments are sent as two parts: One which is a complete e-mail by itself, and one which holds the signature for that e-mail. This is because in attachments whitespace must be preserved (as opposed to the situation in the message itself). It would be very convenient if such e-mail can be handled by python programs without rewriting the things which work fine for non-signed e-mails. If the attachment is really changed, of course the signature will be broken. However, if it is not, it should not be hard to write out the same message (with whitespace preserved) as was read in. If this is not possible, it is quite hard to do it in the program, as python doesn't seem to support loading a part of an e-mail which has headers of its own as a binary attachment (without touching whitespace, in particular). ---------------------------------------------------------------------- Comment By: Jonas Berlin (xkr47) Date: 2005-03-19 13:21 Message: Logged In: YES user_id=66259 from python's Message.py: def _get_params_preserve(self, failobj, header): # Like get_params() but preserves the quoting of values. BAW: # should this be part of the public interface? According to my analysis of the comment, the function in question does _not_ guarantee to preserve the header as-is, it only preserves _quoting_. Thus, I don't think we can call this a bug in python. If there's more official documentation elsewhere that states that it should preserve everything as-is, then ignore this comment altogether :). I didn't have time to grasp how mailman actually uses that Message class, but I think mailman should be changed to use functions that don't alter the message, and/or re-implement that work according to the requirements of mailman (or, users of mailman :). Anyway, an alternative could be to continue to use the Message.py functions to parse the values while analyzing the contents of the message, and then copypaste the original headers as-is after checking. - xkr47 ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2005-01-29 18:08 Message: Logged In: YES user_id=15365 Dear Bas, Thanks a lot for identifying the source of this bug and flagging an upstream bug on Python. Etienne ---------------------------------------------------------------------- Comment By: Bas Wijnen (shevek) Date: 2005-01-24 12:35 Message: Logged In: YES user_id=42389 I checked the source, and this appears to be a bug in Python. It can read and write e-mails, including headers, and they are interpreted. However, it doesn't preserve their whitespace, which is of course fatal for pgp signatures. The bug is filed for python here: http://sourceforge.net/tracker/index.php?func=detail&aid=968430&group_id=54… ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2005-01-18 18:30 Message: Logged In: YES user_id=15365 I am attaching a screen shot of the content filtering settings (see the options.png attachment I have added to this bug report). In short, content filtering is disabled, so I don't think it is the cause of the problem. :-/ Etienne ---------------------------------------------------------------------- Comment By: Brad Knowles (shub) Date: 2005-01-17 01:37 Message: Logged In: YES user_id=18417 Look at your content filter settings. What MIME-types are you configured to pass? At the very least, you should be configured to pass the following: multipart/mixed multipart/alternative text/plain application/pgp-signature multipart/signed ---------------------------------------------------------------------- Comment By: Toni Willberg (toniw) Date: 2005-01-08 02:23 Message: Logged In: YES user_id=190645 I can reproduce this bug also. Here's a diff what happened to me: diff -u mail.valid mail.invalid Content-Disposition: attachment; filename=configure.in.pre-pkgconfig.patch -Content-Type: text/x-patch; name=configure.in.pre-pkgconfig.patch; charset=UTF-8 +Content-Type: text/x-patch; name=configure.in.pre-pkgconfig.patch; + charset=UTF-8 Content-Transfer-Encoding: base64 And this was _inside_ gpg-signed block. Mailman should not alter that section at all, right? X-Mailman-Version: 2.1.4 Yours, Toni Willberg <toniw(a)iki.fi> ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2004-12-30 05:03 Message: Logged In: YES user_id=15365 Any update? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1085651&group_…

1 0

[ mailman-Bugs-1484722 ] Topic regexes are never applied
by SourceForge.net May 11, 2006

May 11, 2006

Bugs item #1484722, was opened at 2006-05-09 07:28 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1484722&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: Pending Resolution: None Priority: 5 Submitted By: Jesse Keating (jkeating-redhat) Assigned to: Nobody/Anonymous (nobody) Summary: Topic regexes are never applied Initial Comment: Topic filters are checked via a provided regex. The code that applies regexes to a message, and tags a message with a topic and adds a header is called Tagger.process. This function is only called by a test/ script, to test the code path. In the production code Tagger.process is never called, so a mail is never checked/tagged with a topic, and thus when later checked for who it should be delivered to based on topic, it has no topic so it doesn't get delivered correctly. This is 2.1.8. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-05-10 20:02 Message: Logged In: YES user_id=1123998 Yes, Tagger is in GLOBAL_PIPELINE, so unless you have redefined GLOBAL_PIPELINE in mm_cfg.py to not include Tagger or the list has a pipeline attribute defined (default lists don't) that doesn't include Tagger, Mailman.Handlers.Tagger.process() is called by IncomingRunner in processing the message through the pipeline. ---------------------------------------------------------------------- Comment By: Jesse Keating (jkeating-redhat) Date: 2006-05-09 07:52 Message: Logged In: YES user_id=1519854 Upon closer looking, it would seem that this could be called through a pipeline. I'm looking in our config to see if we haven't defined this as a pipeline. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1484722&group_…

1 0

[ mailman-Feature Requests-1485689 ] mailpasswds have force option
by SourceForge.net May 10, 2006

May 10, 2006

Feature Requests item #1485689, was opened at 2006-05-10 11:32 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1485689&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: Closed >Resolution: Rejected Priority: 5 Submitted By: jbgorrie (jbgorrie) Assigned to: Nobody/Anonymous (nobody) Summary: mailpasswds have force option Initial Comment: Would be quite useful to include a "force sending to list" even if the default list config prevents password reminders. As well as having the ability to override a user selecting not to receive the password. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-05-10 11:35 Message: Logged In: YES user_id=12800 Rejected because password reminders are a misfeature that will go away in MM2.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1485689&group_…

1 0

[ mailman-Feature Requests-1485689 ] mailpasswds have force option
by SourceForge.net May 10, 2006

May 10, 2006

Feature Requests item #1485689, was opened at 2006-05-10 15:32 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=1485689&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 Submitted By: jbgorrie (jbgorrie) Assigned to: Nobody/Anonymous (nobody) Summary: mailpasswds have force option Initial Comment: Would be quite useful to include a "force sending to list" even if the default list config prevents password reminders. As well as having the ability to override a user selecting not to receive the password. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1485689&group_…

1 0

[ mailman-Bugs-1484722 ] Topic regexes are never applied
by SourceForge.net May 9, 2006

May 9, 2006

Bugs item #1484722, was opened at 2006-05-09 10:28 Message generated for change (Comment added) made by jkeating-redhat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1484722&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 Submitted By: Jesse Keating (jkeating-redhat) Assigned to: Nobody/Anonymous (nobody) Summary: Topic regexes are never applied Initial Comment: Topic filters are checked via a provided regex. The code that applies regexes to a message, and tags a message with a topic and adds a header is called Tagger.process. This function is only called by a test/ script, to test the code path. In the production code Tagger.process is never called, so a mail is never checked/tagged with a topic, and thus when later checked for who it should be delivered to based on topic, it has no topic so it doesn't get delivered correctly. This is 2.1.8. ---------------------------------------------------------------------- >Comment By: Jesse Keating (jkeating-redhat) Date: 2006-05-09 10:52 Message: Logged In: YES user_id=1519854 Upon closer looking, it would seem that this could be called through a pipeline. I'm looking in our config to see if we haven't defined this as a pipeline. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1484722&group_…

1 0

[ mailman-Bugs-1484722 ] Topic regexes are never applied
by SourceForge.net May 9, 2006

May 9, 2006

Bugs item #1484722, was opened at 2006-05-09 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=1484722&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 Submitted By: Jesse Keating (jkeating-redhat) Assigned to: Nobody/Anonymous (nobody) Summary: Topic regexes are never applied Initial Comment: Topic filters are checked via a provided regex. The code that applies regexes to a message, and tags a message with a topic and adds a header is called Tagger.process. This function is only called by a test/ script, to test the code path. In the production code Tagger.process is never called, so a mail is never checked/tagged with a topic, and thus when later checked for who it should be delivered to based on topic, it has no topic so it doesn't get delivered correctly. This is 2.1.8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1484722&group_…

1 0

[ mailman-Patches-1483446 ] Daily mbox files for list mbox archives
by SourceForge.net May 7, 2006

May 7, 2006

Patches item #1483446, was opened at 2006-05-07 18:14 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=1483446&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 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Daily mbox files for list mbox archives Initial Comment: The daily mbox patch changes the way Mailman does its archive-to-mbox archiving, if that is enabled. The standard Mailman system single .mbox file per list used for mbox archiving can, over time, become very unwieldy, presenting problems for disk space management. The mailman daily mbox patch modifies Mailman's behaviour so that a sparse series of daily mbox files is used for archiving rather than a single mbox file. Each archived message is normally appended to a daily mbox file for the UTC date when the message is first archived. For more information, download the patch and check out the file README.dailymbox or visit the URL http://www.openinfo.co.uk/mm/ patches/dailymbox/ Apply the patch from within the Mailman build directory using the command: patch -p1 < path-to-patch-file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1483446&group_…

1 0