From noreply at sourceforge.net Tue Sep 4 01:09:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Sep 2007 16:09:02 -0700 Subject: [ mailman-Patches-731100 ] Postfix XVERP support for SMTPDirect.py Message-ID: Patches item #731100, was opened at 2003-05-01 14:44 Message generated for change (Comment added) made by jfesler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=731100&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: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Colin Palmer (tzs) Assigned to: Nobody/Anonymous (nobody) Summary: Postfix XVERP support for SMTPDirect.py Initial Comment: This patch adds support for Postfix's XVERP ESMTP extension for doing VERP on delivery instead of requiring Mailman to inject the message once per recipient when VERPing. This patch is against Mailman 2.1.2 To make it work, add: VERP_STYLE = 'Postfix' POSTFIX_XVERP_OPTS = '+=' to mm_cfg.py And to go back to Mailman's way of doing VERP, you can set VERP_STYLE = 'Mailman' ---------------------------------------------------------------------- Comment By: Jason Fesler (jfesler) Date: 2007-09-03 12:09 Message: Logged In: YES user_id=239889 Originator: NO I for one find this a valuable contribution. It doesn't apply perfectly cleanly on the latest release of mailman but it does apply pretty easily by hand. This patch makes a big difference on system performance. ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2004-01-02 12:24 Message: Logged In: YES user_id=2788 I have updated the patch for 2.1.4, find it at http://sourceforge.net/tracker/index.php? func=detail&aid=869638&group_id=103&atid=300103 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=731100&group_id=103 From noreply at sourceforge.net Thu Sep 6 06:58:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Sep 2007 21:58:38 -0700 Subject: [ mailman-Bugs-1789138 ] Feature Request -- OpenID support Message-ID: Bugs item #1789138, was opened at 2007-09-05 23:58 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=1789138&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Susan E. S. (meltedtwix) Assigned to: Nobody/Anonymous (nobody) Summary: Feature Request -- OpenID support Initial Comment: I would love to see MailMan accept OpenID as a login method. It would take a load off of those of us with too many mailing lists to keep track of. Information on OpenID is available at OpenID.net Susan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1789138&group_id=103 From noreply at sourceforge.net Sat Sep 8 19:29:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Sep 2007 10:29:11 -0700 Subject: [ mailman-Feature Requests-1286298 ] Feature Request: Admin change subscriber's e-mail Message-ID: Feature Requests item #1286298, was opened at 2005-09-09 15:23 Message generated for change (Comment added) made by nes49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1286298&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 Private: No Submitted By: Dennis Behrens (djbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: Feature Request: Admin change subscriber's e-mail Initial Comment: I would like to be able to go into Membership Management and be able to change a subscriber's e-mail address without sending a confirmation to the user. I'd rather not have to unsubscribe and resubscribe them with a different e-mail address. In my case, I'm taking an old listproc list and moving the user list wholesale into mailman, and then cleaning up the resulting mess. ---------------------------------------------------------------------- Comment By: NancyS (nes49) Date: 2007-09-08 12:29 Message: Logged In: YES user_id=995718 Originator: NO Yes, please. If the administrator can add someone without their confirmation, why is a confirmation required for an address change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1286298&group_id=103 From noreply at sourceforge.net Sat Sep 8 19:33:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Sep 2007 10:33:33 -0700 Subject: [ mailman-Patches-932383 ] Include FullName in roster views Message-ID: Patches item #932383, was opened at 2004-04-09 11:39 Message generated for change (Comment added) made by nes49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=932383&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 UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: M. C. B. (u4forge) Assigned to: Nobody/Anonymous (nobody) Summary: Include FullName in roster views Initial Comment: Patch HTMLFormat.py FormatUsers() to return "fullname" alongside email. This is used by the "Show Members" button on the listinfo page. Patch is for HTMLFormat.py at CVS rev 2.38 (2.1.3) and was tested with rev 2.39. ---------------------------------------------------------------------- Comment By: NancyS (nes49) Date: 2007-09-08 12:33 Message: Logged In: YES user_id=995718 Originator: NO I'm pretty sure this is the patch that I got my sysadmin to install with Mailman 2.1.x back in 2004. Is there any way to vote to get this into the trunk? [With a less friendly sysadmin unwilling to reapply this to each of the several 2.1 releases, this functionality has been lost in my installations.] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=932383&group_id=103 From noreply at sourceforge.net Sat Sep 8 19:59:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Sep 2007 10:59:16 -0700 Subject: [ mailman-Feature Requests-1269067 ] e-mail command confirmations should be optional Message-ID: Feature Requests item #1269067, was opened at 2005-08-24 15:09 Message generated for change (Comment added) made by nes49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269067&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 Private: No Submitted By: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: e-mail command confirmations should be optional Initial Comment: When we send an e-mail to change the member's options with a command (e.g. to subscribe/unsubscribe members), the confirmation of the commands should be optionnal. This is useful particularly if we do a php script that sends the commands automatically from a post field. Then the member doesn't need to see all those e-mail commands. This should be an optional command that would disable these confirmations for the whole list and all commands. www.Sympa.org mailing list does this very well. Thank you. Daniel ---------------------------------------------------------------------- Comment By: NancyS (nes49) Date: 2007-09-08 12:59 Message: Logged In: YES user_id=995718 Originator: NO Yes, please. If the admin can subscribe an address without a confirmation, then they should also be able to change the address. Forcing kludges like unsubscribe the old address and subscribe a new one risks losing the changes that a subscriber may have made. [Yes, if they made changes, they should be expected to respond to the confirmation, but there's no way to tell if they are one of the subscribers that understands the web interface or not.] ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-11-09 04:51 Message: Logged In: YES user_id=1320890 Ok, thank you for that information, it works now. I understand your concern, and allowing free subscriptions from only certain hosts would be an idea of new feature request. It's my case where it's always the server that send an e-mail to mailman to subscribe people. It is a bit more difficult for people to use my script by spoofing it, and I can prevent more than 3 e-mails per day per IP address if really needed. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-08 20:28 Message: Logged In: YES user_id=1123998 I'm moving this to "Feature Requests" as it is not a bug. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-03 20:24 Message: Logged In: YES user_id=1123998 In general, I think this is a bad idea because it allows anyone to subscribe anyone else to a list by spoofing their email address in an email command. If you really want to open up subscribing without confirmation, that feature is already available. Put ALLOW_OPEN_SUBSCRIBE = Yes in mm_cfg.py and lists will have a None option for subscribe_policy which will allow subscribe without confirmation. ---------------------------------------------------------------------- Comment By: moshe weitzman (weitzman) Date: 2005-11-03 09:05 Message: Logged In: YES user_id=199362 I too need this. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269067&group_id=103 From noreply at sourceforge.net Sat Sep 8 20:05:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Sep 2007 11:05:46 -0700 Subject: [ mailman-Feature Requests-1790772 ] Allow Ademin to list/change subscriptions on other lists Message-ID: Feature Requests item #1790772, was opened at 2007-09-08 13:05 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=1790772&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 Private: No Submitted By: NancyS (nes49) Assigned to: Nobody/Anonymous (nobody) Summary: Allow Ademin to list/change subscriptions on other lists Initial Comment: While I understand some of the reasons why allowing an admin to list/change subscriptions on other lists may not be appropriate for all installations, I'd like to see this pre-2.1.9 functionality return to Mailman. Perhaps it could be implemented as an option on a per-virtual-domain basis. For virtual domains where all the lists support one community and are administered by the same people, allowing an administrator to, say, change a subscriber's address on all the lists at one time is invaluable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1790772&group_id=103 From noreply at sourceforge.net Sat Sep 8 20:06:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Sep 2007 11:06:28 -0700 Subject: [ mailman-Feature Requests-1790772 ] Allow Admin to list/change subscriptions on other lists Message-ID: Feature Requests item #1790772, was opened at 2007-09-08 13:05 Message generated for change (Settings changed) made by nes49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1790772&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 Private: No Submitted By: NancyS (nes49) Assigned to: Nobody/Anonymous (nobody) >Summary: Allow Admin to list/change subscriptions on other lists Initial Comment: While I understand some of the reasons why allowing an admin to list/change subscriptions on other lists may not be appropriate for all installations, I'd like to see this pre-2.1.9 functionality return to Mailman. Perhaps it could be implemented as an option on a per-virtual-domain basis. For virtual domains where all the lists support one community and are administered by the same people, allowing an administrator to, say, change a subscriber's address on all the lists at one time is invaluable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1790772&group_id=103 From noreply at sourceforge.net Sun Sep 9 00:43:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Sep 2007 15:43:58 -0700 Subject: [ mailman-Feature Requests-1269067 ] e-mail command confirmations should be optional Message-ID: Feature Requests item #1269067, was opened at 2005-08-24 13:09 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269067&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 Private: No Submitted By: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: e-mail command confirmations should be optional Initial Comment: When we send an e-mail to change the member's options with a command (e.g. to subscribe/unsubscribe members), the confirmation of the commands should be optionnal. This is useful particularly if we do a php script that sends the commands automatically from a post field. Then the member doesn't need to see all those e-mail commands. This should be an optional command that would disable these confirmations for the whole list and all commands. www.Sympa.org mailing list does this very well. Thank you. Daniel ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2007-09-08 15:43 Message: Logged In: YES user_id=1123998 Originator: NO Users should not be able to change their subscription address without confirmation unless the site has chosen to allow open subscribes and the list is so configured. Otherwise, anyone can maliciously subscribe anyone else by first subscribing themselves, confirming and then changing their address to the target. What you (nes49) want is for an admin to be able to change a user's address without the user's confirmation. I agree with your reasoning, but that is not what this request is about. My 2005-11-03 comment was about user's subscribing without confirmation, but as I read this request today, I think it merely asks that the user be able to supress the "results of your email commands" informational email. ---------------------------------------------------------------------- Comment By: NancyS (nes49) Date: 2007-09-08 10:59 Message: Logged In: YES user_id=995718 Originator: NO Yes, please. If the admin can subscribe an address without a confirmation, then they should also be able to change the address. Forcing kludges like unsubscribe the old address and subscribe a new one risks losing the changes that a subscriber may have made. [Yes, if they made changes, they should be expected to respond to the confirmation, but there's no way to tell if they are one of the subscribers that understands the web interface or not.] ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-11-09 01:51 Message: Logged In: YES user_id=1320890 Ok, thank you for that information, it works now. I understand your concern, and allowing free subscriptions from only certain hosts would be an idea of new feature request. It's my case where it's always the server that send an e-mail to mailman to subscribe people. It is a bit more difficult for people to use my script by spoofing it, and I can prevent more than 3 e-mails per day per IP address if really needed. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-08 17:28 Message: Logged In: YES user_id=1123998 I'm moving this to "Feature Requests" as it is not a bug. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-03 17:24 Message: Logged In: YES user_id=1123998 In general, I think this is a bad idea because it allows anyone to subscribe anyone else to a list by spoofing their email address in an email command. If you really want to open up subscribing without confirmation, that feature is already available. Put ALLOW_OPEN_SUBSCRIBE = Yes in mm_cfg.py and lists will have a None option for subscribe_policy which will allow subscribe without confirmation. ---------------------------------------------------------------------- Comment By: moshe weitzman (weitzman) Date: 2005-11-03 06:05 Message: Logged In: YES user_id=199362 I too need this. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269067&group_id=103 From noreply at sourceforge.net Sun Sep 9 01:15:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Sep 2007 16:15:55 -0700 Subject: [ mailman-Feature Requests-1269067 ] e-mail command confirmations should be optional Message-ID: Feature Requests item #1269067, was opened at 2005-08-24 20:09 Message generated for change (Comment added) made by doolyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269067&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 Private: No Submitted By: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: e-mail command confirmations should be optional Initial Comment: When we send an e-mail to change the member's options with a command (e.g. to subscribe/unsubscribe members), the confirmation of the commands should be optionnal. This is useful particularly if we do a php script that sends the commands automatically from a post field. Then the member doesn't need to see all those e-mail commands. This should be an optional command that would disable these confirmations for the whole list and all commands. www.Sympa.org mailing list does this very well. Thank you. Daniel ---------------------------------------------------------------------- >Comment By: Daniel (doolyo) Date: 2007-09-08 23:15 Message: Logged In: YES user_id=1320890 Originator: YES Hello, msapiro. Yes, what I was requesting at first was that we would be able to choose to receive the informationnal confirmation or not. If you have an external script which registers e-mail adresses, you don't want the user to receive the e-mail commands that you sent to accomplish this action (register/unregister), because the script did it and not himself, so he wouldn't understand a lot about this confirmation, and the goal is also to send a personnalised informationnal confirmation to each user instead of the standard one as we immediately see that Mailman is the e-mail manager. Therefore I was surprised that there was no option to disable this informational confirmation to the user. Or else maybe there is one but I didn't find it at least. Thanks ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2007-09-08 22:43 Message: Logged In: YES user_id=1123998 Originator: NO Users should not be able to change their subscription address without confirmation unless the site has chosen to allow open subscribes and the list is so configured. Otherwise, anyone can maliciously subscribe anyone else by first subscribing themselves, confirming and then changing their address to the target. What you (nes49) want is for an admin to be able to change a user's address without the user's confirmation. I agree with your reasoning, but that is not what this request is about. My 2005-11-03 comment was about user's subscribing without confirmation, but as I read this request today, I think it merely asks that the user be able to supress the "results of your email commands" informational email. ---------------------------------------------------------------------- Comment By: NancyS (nes49) Date: 2007-09-08 17:59 Message: Logged In: YES user_id=995718 Originator: NO Yes, please. If the admin can subscribe an address without a confirmation, then they should also be able to change the address. Forcing kludges like unsubscribe the old address and subscribe a new one risks losing the changes that a subscriber may have made. [Yes, if they made changes, they should be expected to respond to the confirmation, but there's no way to tell if they are one of the subscribers that understands the web interface or not.] ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-11-09 09:51 Message: Logged In: YES user_id=1320890 Ok, thank you for that information, it works now. I understand your concern, and allowing free subscriptions from only certain hosts would be an idea of new feature request. It's my case where it's always the server that send an e-mail to mailman to subscribe people. It is a bit more difficult for people to use my script by spoofing it, and I can prevent more than 3 e-mails per day per IP address if really needed. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-09 01:28 Message: Logged In: YES user_id=1123998 I'm moving this to "Feature Requests" as it is not a bug. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-04 01:24 Message: Logged In: YES user_id=1123998 In general, I think this is a bad idea because it allows anyone to subscribe anyone else to a list by spoofing their email address in an email command. If you really want to open up subscribing without confirmation, that feature is already available. Put ALLOW_OPEN_SUBSCRIBE = Yes in mm_cfg.py and lists will have a None option for subscribe_policy which will allow subscribe without confirmation. ---------------------------------------------------------------------- Comment By: moshe weitzman (weitzman) Date: 2005-11-03 14:05 Message: Logged In: YES user_id=199362 I too need this. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269067&group_id=103 From noreply at sourceforge.net Sun Sep 9 01:38:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Sep 2007 16:38:05 -0700 Subject: [ mailman-Feature Requests-1790892 ] Allow Admin to change subscription address w/o confirmation Message-ID: Feature Requests item #1790892, was opened at 2007-09-08 18:38 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=1790892&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 Private: No Submitted By: NancyS (nes49) Assigned to: Nobody/Anonymous (nobody) Summary: Allow Admin to change subscription address w/o confirmation Initial Comment: In lists that serve non-technical communities, there's a problem with subscribers who don't understand the confirmation messages or just don't reply to them. In that case, administrators often explicitly subscribe almost all the users, using some "offline" method to ensure that the users do wish to be subscribed. But when a subscriber address changes, it's not easy for the administrator to change the address reliably. Since the "address change" on the user options page will generate a confirmation message that the subscriber will likely ignore, administrators who don't have access to the clone command may choose to use an unsubscribe/subscribe strategy to get the list up to date. This, of course, risks losing user-configured options, but is an attractive path for those who have struggled and failed to explain confirmation messages. If an administrator can subscribe an address without confirmation, user confirmation should not be required to change that address. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1790892&group_id=103 From noreply at sourceforge.net Sun Sep 9 17:44:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Sep 2007 08:44:18 -0700 Subject: [ mailman-Feature Requests-1790892 ] Allow Admin to change subscription address w/o confirmation Message-ID: Feature Requests item #1790892, was opened at 2007-09-08 18:38 Message generated for change (Comment added) made by nes49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1790892&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 Private: No Submitted By: NancyS (nes49) Assigned to: Nobody/Anonymous (nobody) Summary: Allow Admin to change subscription address w/o confirmation Initial Comment: In lists that serve non-technical communities, there's a problem with subscribers who don't understand the confirmation messages or just don't reply to them. In that case, administrators often explicitly subscribe almost all the users, using some "offline" method to ensure that the users do wish to be subscribed. But when a subscriber address changes, it's not easy for the administrator to change the address reliably. Since the "address change" on the user options page will generate a confirmation message that the subscriber will likely ignore, administrators who don't have access to the clone command may choose to use an unsubscribe/subscribe strategy to get the list up to date. This, of course, risks losing user-configured options, but is an attractive path for those who have struggled and failed to explain confirmation messages. If an administrator can subscribe an address without confirmation, user confirmation should not be required to change that address. ---------------------------------------------------------------------- >Comment By: NancyS (nes49) Date: 2007-09-09 10:44 Message: Logged In: YES user_id=995718 Originator: YES Deleted as dup of 1286298. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1790892&group_id=103 From noreply at sourceforge.net Sun Sep 9 17:44:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Sep 2007 08:44:46 -0700 Subject: [ mailman-Feature Requests-1790892 ] Allow Admin to change subscription address w/o confirmation Message-ID: Feature Requests item #1790892, was opened at 2007-09-08 18:38 Message generated for change (Settings changed) made by nes49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1790892&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: Deleted Resolution: None Priority: 5 Private: No Submitted By: NancyS (nes49) Assigned to: Nobody/Anonymous (nobody) Summary: Allow Admin to change subscription address w/o confirmation Initial Comment: In lists that serve non-technical communities, there's a problem with subscribers who don't understand the confirmation messages or just don't reply to them. In that case, administrators often explicitly subscribe almost all the users, using some "offline" method to ensure that the users do wish to be subscribed. But when a subscriber address changes, it's not easy for the administrator to change the address reliably. Since the "address change" on the user options page will generate a confirmation message that the subscriber will likely ignore, administrators who don't have access to the clone command may choose to use an unsubscribe/subscribe strategy to get the list up to date. This, of course, risks losing user-configured options, but is an attractive path for those who have struggled and failed to explain confirmation messages. If an administrator can subscribe an address without confirmation, user confirmation should not be required to change that address. ---------------------------------------------------------------------- Comment By: NancyS (nes49) Date: 2007-09-09 10:44 Message: Logged In: YES user_id=995718 Originator: YES Deleted as dup of 1286298. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1790892&group_id=103 From noreply at sourceforge.net Sun Sep 9 22:56:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Sep 2007 13:56:42 -0700 Subject: [ mailman-Feature Requests-1286298 ] Feature Request: Admin change subscriber's e-mail Message-ID: Feature Requests item #1286298, was opened at 2005-09-09 13:23 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1286298&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 Private: No Submitted By: Dennis Behrens (djbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: Feature Request: Admin change subscriber's e-mail Initial Comment: I would like to be able to go into Membership Management and be able to change a subscriber's e-mail address without sending a confirmation to the user. I'd rather not have to unsubscribe and resubscribe them with a different e-mail address. In my case, I'm taking an old listproc list and moving the user list wholesale into mailman, and then cleaning up the resulting mess. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2007-09-09 13:56 Message: Logged In: YES user_id=1123998 Originator: NO I have some implementation questions. The simplest way to do this is to check in the options page processing for authorization by list or site admin and if so, skip the confirmation of an address change. However, this is a substantive change of behavior and could be a big surprise for an admin who expected the change to require confirmation. So is this change in behavior acceptable? If not, what shoud the UI look like for an address change? Should it still be on the options page with a note for admins only that it won't be confirmed or a check box for admins only to bypass confirmation, or should it be a new function in membership management? ---------------------------------------------------------------------- Comment By: NancyS (nes49) Date: 2007-09-08 10:29 Message: Logged In: YES user_id=995718 Originator: NO Yes, please. If the administrator can add someone without their confirmation, why is a confirmation required for an address change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1286298&group_id=103 From noreply at sourceforge.net Mon Sep 10 00:06:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Sep 2007 15:06:36 -0700 Subject: [ mailman-Feature Requests-1286298 ] Feature Request: Admin change subscriber's e-mail Message-ID: Feature Requests item #1286298, was opened at 2005-09-09 15:23 Message generated for change (Comment added) made by djbehrens You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1286298&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 Private: No Submitted By: Dennis Behrens (djbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: Feature Request: Admin change subscriber's e-mail Initial Comment: I would like to be able to go into Membership Management and be able to change a subscriber's e-mail address without sending a confirmation to the user. I'd rather not have to unsubscribe and resubscribe them with a different e-mail address. In my case, I'm taking an old listproc list and moving the user list wholesale into mailman, and then cleaning up the resulting mess. ---------------------------------------------------------------------- >Comment By: Dennis Behrens (djbehrens) Date: 2007-09-09 17:06 Message: Logged In: YES user_id=1342289 Originator: YES I would think the best place for this would be the membership management page. There is a checkbox to unsub the subscriber, I would think another checkbox could be added to edit the subscriber's address. Then another page would load to be able to edit the e-mail address, and then there could be a checkbox on that page to make the change without sending the subscriber confirmation e-mails. Also I would think if a change is made on the options page processing that this could possibly lead to un-intended list config change--and might cause more problems than it's worth. The main reason I requested this feature was in migrating an old listproc list, where a user was subscribed as user at mailhost.somedomain.com their emails would be stamped as user at somedomain.com or user at mailhost.xyz.somedomain.com--and obviously mailman would reject their e-mail postings (as being a list that only subscribers can post to.) ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2007-09-09 15:56 Message: Logged In: YES user_id=1123998 Originator: NO I have some implementation questions. The simplest way to do this is to check in the options page processing for authorization by list or site admin and if so, skip the confirmation of an address change. However, this is a substantive change of behavior and could be a big surprise for an admin who expected the change to require confirmation. So is this change in behavior acceptable? If not, what shoud the UI look like for an address change? Should it still be on the options page with a note for admins only that it won't be confirmed or a check box for admins only to bypass confirmation, or should it be a new function in membership management? ---------------------------------------------------------------------- Comment By: NancyS (nes49) Date: 2007-09-08 12:29 Message: Logged In: YES user_id=995718 Originator: NO Yes, please. If the administrator can add someone without their confirmation, why is a confirmation required for an address change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1286298&group_id=103 From noreply at sourceforge.net Tue Sep 11 02:58:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Sep 2007 17:58:21 -0700 Subject: [ mailman-Bugs-1792087 ] Mailman changes attachment filenames Message-ID: Bugs item #1792087, was opened at 2007-09-10 20:58 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=1792087&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 Private: No Submitted By: Steven (madrobin) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman changes attachment filenames Initial Comment: Hello! I'm using Mailman version 2.1.9.cp2, hosted by site5.com. When sending attachments with long filenames to a list, the file name arrives with one character substituted for another. The attachments with the changed filename cannot be opened in the FirstClass email client. The attachment names were: 2007 September Using FirstClass To Book School Resources.pdf and 2007 September Teaching Lab Expectations and Routines.pdf In both cases, when the attachment filenames were viewed in FirstClass after having been delivered by Mailman, the last space in the filename had been converted to a character which looks like a square. I am attaching a screenshot. If I try to open the attachment in FirstClass, I receive an error dialog box: File Transfer Failed because File not open error [1210:4104] I am not able to open the attachment. If I send the same attachments with the same filenames "directly" (not through Mailman) and open them in FirstClass, there is no problem. The filenames do not change and the attachments can be opened without difficulty. If I shorten the attachment filenames (for example, I removed the "2007 September" part of the above filenames) and send them through Mailman, there is also no problem; the filenames do not change and the attachments can be opened. I also tried viewing the long-filename attachments sent via Mailman in a different email client (Pegasus Mail). The attachment filenames had again been changed (instead of a square, the character which had been substituted for the last space looked more like a thick vertical bar.) However, even with the filename change, Pegasus Mail was still able to open the attachments. (Unfortunately, my employer allows us to use only FirstClass.) I was not able to find anything addressing this problem. However, if I missed it and you can point me in the direction of a solution, I would greatly appreciate it. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1792087&group_id=103 From noreply at sourceforge.net Tue Sep 11 03:31:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Sep 2007 18:31:38 -0700 Subject: [ mailman-Bugs-1792087 ] Mailman changes attachment filenames Message-ID: Bugs item #1792087, was opened at 2007-09-10 17:58 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1792087&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 Private: No Submitted By: Steven (madrobin) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman changes attachment filenames Initial Comment: Hello! I'm using Mailman version 2.1.9.cp2, hosted by site5.com. When sending attachments with long filenames to a list, the file name arrives with one character substituted for another. The attachments with the changed filename cannot be opened in the FirstClass email client. The attachment names were: 2007 September Using FirstClass To Book School Resources.pdf and 2007 September Teaching Lab Expectations and Routines.pdf In both cases, when the attachment filenames were viewed in FirstClass after having been delivered by Mailman, the last space in the filename had been converted to a character which looks like a square. I am attaching a screenshot. If I try to open the attachment in FirstClass, I receive an error dialog box: File Transfer Failed because File not open error [1210:4104] I am not able to open the attachment. If I send the same attachments with the same filenames "directly" (not through Mailman) and open them in FirstClass, there is no problem. The filenames do not change and the attachments can be opened without difficulty. If I shorten the attachment filenames (for example, I removed the "2007 September" part of the above filenames) and send them through Mailman, there is also no problem; the filenames do not change and the attachments can be opened. I also tried viewing the long-filename attachments sent via Mailman in a different email client (Pegasus Mail). The attachment filenames had again been changed (instead of a square, the character which had been substituted for the last space looked more like a thick vertical bar.) However, even with the filename change, Pegasus Mail was still able to open the attachments. (Unfortunately, my employer allows us to use only FirstClass.) I was not able to find anything addressing this problem. However, if I missed it and you can point me in the direction of a solution, I would greatly appreciate it. Thank you. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2007-09-10 18:31 Message: Logged In: YES user_id=1123998 Originator: NO This appears to be a problem with header folding and unfolding resulting in the being possibly replaced by a which is shown as an 'invalid character' (the square symbol) by the mail client. Can you save the attachment and then open the saved file outside of FirstClass (perhaps after changing it's name or 'saving as' and providing a 'good' name)? I am unable to know what is at fault here without seeing the raw headers of the attachment part from the mail as sent and the mail as received from Mailman. It may be a Mailman issue, a cPanel issue or a FirstClass issue. Also, please see . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1792087&group_id=103 From noreply at sourceforge.net Tue Sep 11 22:43:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Sep 2007 13:43:55 -0700 Subject: [ mailman-Bugs-1792725 ] Translation error in mailman DE Message-ID: Bugs item #1792725, was opened at 2007-09-11 22:43 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=1792725&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 Private: No Submitted By: Christian K?hn (tksham) Assigned to: Nobody/Anonymous (nobody) Summary: Translation error in mailman DE Initial Comment: just a very small mistake, bus this is the diff to the correct translation: --- mailman.po.orig 2007-09-11 10:46:28.000000000 +0200 +++ mailman.po 2007-09-11 10:29:06.000000000 +0200 @@ -3971,7 +3971,7 @@ # Mailman/MailCommandHandler.py:656 #: Mailman/Commands/cmd_subscribe.py:121 msgid "You are already subscribed!" -msgstr "Sie sind bereits Abonnement!" +msgstr "Sie sind bereits Abonnent!" # Mailman/Cgi/subscribe.py:198 Mailman/MailCommandHandler.py:659 #: Mailman/Commands/cmd_subscribe.py:125 Kind Regards Christian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1792725&group_id=103 From noreply at sourceforge.net Wed Sep 12 23:54:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Sep 2007 14:54:18 -0700 Subject: [ mailman-Bugs-1793548 ] Attachment Errors Message-ID: Bugs item #1793548, was opened at 2007-09-12 16:54 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=1793548&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 Private: No Submitted By: matt (matt_ideawire) Assigned to: Nobody/Anonymous (nobody) Summary: Attachment Errors Initial Comment: I wouldn't classify this issue as a software bug, but it seems a logical place to raise my question: Is anyone else having recent difficulties sending attachments using Mailman? The fact that the issue is recent points me to the ISP blocking this traffic as SPAM. If my theory is correct, it should be a known and widely published issue. That is not the case. I've been through every security check I can think of on the Mailman interface and on the server, and everything looks fine. Forgive my ignorance concerning Mailman, it's a new app to me in an entirely new environment. I'm trying to ramp up as quickly as possible. Also, apologies if this post is in the incorrect area. I'll happily subject myself to beatings and torture if it means someone who can guide me in the right direction looks at this question. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1793548&group_id=103 From noreply at sourceforge.net Sat Sep 15 20:38:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Sep 2007 11:38:05 -0700 Subject: [ mailman-Bugs-1795553 ] No corresponding message in queue Message-ID: Bugs item #1795553, was opened at 2007-09-15 18:38 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=1795553&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 Private: Yes Submitted By: peter.f.maclean (campaigns) Assigned to: Nobody/Anonymous (nobody) Summary: No corresponding message in queue Initial Comment: As a moderator, I get a notice that there is a message in the queue when there is none. ? From: natex-exnat-bounces at cfs-fcee.ca Subject: 4 natex-exnat moderator request(s) waiting Date: September 15, 2007 9:00:04 AM EDT (CA) To: natex-exnat-owner at cfs-fcee.ca The natex-exnat at cfs-fcee.ca mailing list has 4 request(s) waiting for your consideration at: http://lists.cfs-fcee.ca/mailman/admindb/natex-exnat Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: chair at cfs-fcee.ca on Wed Aug 29 09:24:04 2007 Subject: Teleconference Details Cause: Post to moderated list From: chair at cfs-fcee.ca on Wed Aug 29 10:04:24 2007 Subject: Teleconference Details Cause: Post to moderated list From: chair at cfs-fcee.ca on Thu Aug 30 10:07:39 2007 Subject: Teleconference Agenda Cause: Post to moderated list From: national at cfs.bc.ca on Thu Aug 30 19:46:56 2007 Subject: Fwd: BC-Exec: Job Posting: Organiser-Internal Affairs Cause: Post to moderated list ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1795553&group_id=103 From noreply at sourceforge.net Sat Sep 15 22:12:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Sep 2007 13:12:32 -0700 Subject: [ mailman-Bugs-1795553 ] No corresponding message in queue Message-ID: Bugs item #1795553, was opened at 2007-09-15 11:38 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1795553&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 Private: Yes Submitted By: peter.f.maclean (campaigns) Assigned to: Nobody/Anonymous (nobody) Summary: No corresponding message in queue Initial Comment: As a moderator, I get a notice that there is a message in the queue when there is none. ? From: natex-exnat-bounces at cfs-fcee.ca Subject: 4 natex-exnat moderator request(s) waiting Date: September 15, 2007 9:00:04 AM EDT (CA) To: natex-exnat-owner at cfs-fcee.ca The natex-exnat at cfs-fcee.ca mailing list has 4 request(s) waiting for your consideration at: http://lists.cfs-fcee.ca/mailman/admindb/natex-exnat Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: chair at cfs-fcee.ca on Wed Aug 29 09:24:04 2007 Subject: Teleconference Details Cause: Post to moderated list From: chair at cfs-fcee.ca on Wed Aug 29 10:04:24 2007 Subject: Teleconference Details Cause: Post to moderated list From: chair at cfs-fcee.ca on Thu Aug 30 10:07:39 2007 Subject: Teleconference Agenda Cause: Post to moderated list From: national at cfs.bc.ca on Thu Aug 30 19:46:56 2007 Subject: Fwd: BC-Exec: Job Posting: Organiser-Internal Affairs Cause: Post to moderated list ? ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2007-09-15 13:12 Message: Logged In: YES user_id=1123998 Originator: NO If you receive this notice, and you visit the page and there are no requests waiting, and you get the same notice the next day with the same messages, then the notice is coming from a prior or test installation of Mailman that is still running. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1795553&group_id=103 From noreply at sourceforge.net Sun Sep 16 20:23:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Sep 2007 11:23:28 -0700 Subject: [ mailman-Bugs-1793548 ] Attachment Errors Message-ID: Bugs item #1793548, was opened at 2007-09-12 14:54 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1793548&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 Private: No Submitted By: matt (matt_ideawire) Assigned to: Nobody/Anonymous (nobody) Summary: Attachment Errors Initial Comment: I wouldn't classify this issue as a software bug, but it seems a logical place to raise my question: Is anyone else having recent difficulties sending attachments using Mailman? The fact that the issue is recent points me to the ISP blocking this traffic as SPAM. If my theory is correct, it should be a known and widely published issue. That is not the case. I've been through every security check I can think of on the Mailman interface and on the server, and everything looks fine. Forgive my ignorance concerning Mailman, it's a new app to me in an entirely new environment. I'm trying to ramp up as quickly as possible. Also, apologies if this post is in the incorrect area. I'll happily subject myself to beatings and torture if it means someone who can guide me in the right direction looks at this question. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2007-09-14 08:20 Message: Logged In: YES user_id=1123998 Originator: NO Check out the mailman-users at python.org list . That is a more appropriate place to discuss an issue like this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1793548&group_id=103 From noreply at sourceforge.net Sun Sep 16 20:28:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Sep 2007 11:28:06 -0700 Subject: [ mailman-Bugs-1793548 ] Attachment Errors Message-ID: Bugs item #1793548, was opened at 2007-09-12 14:54 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1793548&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 Private: No Submitted By: matt (matt_ideawire) Assigned to: Nobody/Anonymous (nobody) Summary: Attachment Errors Initial Comment: I wouldn't classify this issue as a software bug, but it seems a logical place to raise my question: Is anyone else having recent difficulties sending attachments using Mailman? The fact that the issue is recent points me to the ISP blocking this traffic as SPAM. If my theory is correct, it should be a known and widely published issue. That is not the case. I've been through every security check I can think of on the Mailman interface and on the server, and everything looks fine. Forgive my ignorance concerning Mailman, it's a new app to me in an entirely new environment. I'm trying to ramp up as quickly as possible. Also, apologies if this post is in the incorrect area. I'll happily subject myself to beatings and torture if it means someone who can guide me in the right direction looks at this question. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2007-09-14 08:20 Message: Logged In: YES user_id=1123998 Originator: NO Check out the mailman-users at python.org list . That is a more appropriate place to discuss an issue like this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1793548&group_id=103 From noreply at sourceforge.net Mon Sep 17 01:16:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Sep 2007 16:16:53 -0700 Subject: [ mailman-Bugs-1792087 ] Mailman changes attachment filenames Message-ID: Bugs item #1792087, was opened at 2007-09-10 20:58 Message generated for change (Comment added) made by madrobin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1792087&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 Private: No Submitted By: Steven (madrobin) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman changes attachment filenames Initial Comment: Hello! I'm using Mailman version 2.1.9.cp2, hosted by site5.com. When sending attachments with long filenames to a list, the file name arrives with one character substituted for another. The attachments with the changed filename cannot be opened in the FirstClass email client. The attachment names were: 2007 September Using FirstClass To Book School Resources.pdf and 2007 September Teaching Lab Expectations and Routines.pdf In both cases, when the attachment filenames were viewed in FirstClass after having been delivered by Mailman, the last space in the filename had been converted to a character which looks like a square. I am attaching a screenshot. If I try to open the attachment in FirstClass, I receive an error dialog box: File Transfer Failed because File not open error [1210:4104] I am not able to open the attachment. If I send the same attachments with the same filenames "directly" (not through Mailman) and open them in FirstClass, there is no problem. The filenames do not change and the attachments can be opened without difficulty. If I shorten the attachment filenames (for example, I removed the "2007 September" part of the above filenames) and send them through Mailman, there is also no problem; the filenames do not change and the attachments can be opened. I also tried viewing the long-filename attachments sent via Mailman in a different email client (Pegasus Mail). The attachment filenames had again been changed (instead of a square, the character which had been substituted for the last space looked more like a thick vertical bar.) However, even with the filename change, Pegasus Mail was still able to open the attachments. (Unfortunately, my employer allows us to use only FirstClass.) I was not able to find anything addressing this problem. However, if I missed it and you can point me in the direction of a solution, I would greatly appreciate it. Thank you. ---------------------------------------------------------------------- >Comment By: Steven (madrobin) Date: 2007-09-16 19:16 Message: Logged In: YES user_id=1719544 Originator: YES Hello! Thanks very much for your reply. I have tried your suggestions about renaming the attachments in FirstClass, but it does not seem to be possible. If I try to "save" rather than "open" the attachments, I get an immediate "file input/output error" and that's that. I would be able to send you a copy of the "internet headers" from the message as it was received in FirstClass, as well as the headers of the copy of the message which I saved in Pegasus Mail when the message was being sent. Is this what you need? I'm not sure that this is something I would want to post in a public forum. Can I email them to you? Thanks again for your help. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2007-09-10 21:31 Message: Logged In: YES user_id=1123998 Originator: NO This appears to be a problem with header folding and unfolding resulting in the being possibly replaced by a which is shown as an 'invalid character' (the square symbol) by the mail client. Can you save the attachment and then open the saved file outside of FirstClass (perhaps after changing it's name or 'saving as' and providing a 'good' name)? I am unable to know what is at fault here without seeing the raw headers of the attachment part from the mail as sent and the mail as received from Mailman. It may be a Mailman issue, a cPanel issue or a FirstClass issue. Also, please see . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1792087&group_id=103 From noreply at sourceforge.net Tue Sep 18 19:28:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Sep 2007 10:28:28 -0700 Subject: [ mailman-Bugs-1792087 ] Mailman changes attachment filenames Message-ID: Bugs item #1792087, was opened at 2007-09-10 17:58 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1792087&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 Private: No Submitted By: Steven (madrobin) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman changes attachment filenames Initial Comment: Hello! I'm using Mailman version 2.1.9.cp2, hosted by site5.com. When sending attachments with long filenames to a list, the file name arrives with one character substituted for another. The attachments with the changed filename cannot be opened in the FirstClass email client. The attachment names were: 2007 September Using FirstClass To Book School Resources.pdf and 2007 September Teaching Lab Expectations and Routines.pdf In both cases, when the attachment filenames were viewed in FirstClass after having been delivered by Mailman, the last space in the filename had been converted to a character which looks like a square. I am attaching a screenshot. If I try to open the attachment in FirstClass, I receive an error dialog box: File Transfer Failed because File not open error [1210:4104] I am not able to open the attachment. If I send the same attachments with the same filenames "directly" (not through Mailman) and open them in FirstClass, there is no problem. The filenames do not change and the attachments can be opened without difficulty. If I shorten the attachment filenames (for example, I removed the "2007 September" part of the above filenames) and send them through Mailman, there is also no problem; the filenames do not change and the attachments can be opened. I also tried viewing the long-filename attachments sent via Mailman in a different email client (Pegasus Mail). The attachment filenames had again been changed (instead of a square, the character which had been substituted for the last space looked more like a thick vertical bar.) However, even with the filename change, Pegasus Mail was still able to open the attachments. (Unfortunately, my employer allows us to use only FirstClass.) I was not able to find anything addressing this problem. However, if I missed it and you can point me in the direction of a solution, I would greatly appreciate it. Thank you. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2007-09-18 10:28 Message: Logged In: YES user_id=1123998 Originator: NO I have received the 'before and after' messages, and the problem is because of header folding and unfolding. There have been discussions of this on the mailman-*@python.org email lists. One example is at which happens to address Subject: headers, but the issue is the same. In this particular case, the original message attachment contains the header Content-disposition: attachment; filename="Test document saved with a very long file name to see if it can be determined what is messing up.pdf" all on one line even though it is probably split here. In Mailman's processing of this message, the underlying Python email library methods determine that this header exceeds the 78 character recommended maximum length and thus folds it into Content-disposition: attachment; filename="Test document saved with a very long file name to see if it can be determined what is messing up.pdf" where represents an ascii tab character. The first fold (between attachment; and filename=) occurs at a 'higher level syntactic break' as recommended by the RFCs, but the filename itself is still too long so it is folded onto a third continuation. The basic issue revolves around the rules for folding and unfolding long header lines. The original standard was RFC 822 , sec 3.1.1. The current recommendation is RFC 2822 , sec 2.2.3. Mailman via the Python email library is not doing the right thing according to these standards. Mailman is replacing a with in order to fold the header. This works unambiguously for the first fold at a syntactic break, but in the second case it doesn't work. FirstClass is doing the right thing in unfolding by removing only the , but this leaves the in the middle of the file name which causes a problem for FirstClass. Because of the ambiguities between RFC 822 and RFC 2822, it is more common for mail clients to remove a whitespace character when unfolding. In this case, that would have the effect of removing the space between 'file name' and 'to see'. This also is an incorrect result, but not as bad. The correct (RFC 2822) thing for the python email library to do would be to fold by just inserting immediately after 'attachment;' and also immediately before ' to see'. This would not be a complete solution to these issues as long as there were common mail clients the removed whitespace when unfolding, but it might minimize the damage. Note that this is really a Python email library issue, not a Mailman issue. In the mean time, the problem can possibly be avoided by avoiding spaces in file names. Use underscores instead. ---------------------------------------------------------------------- Comment By: Steven (madrobin) Date: 2007-09-16 16:16 Message: Logged In: YES user_id=1719544 Originator: YES Hello! Thanks very much for your reply. I have tried your suggestions about renaming the attachments in FirstClass, but it does not seem to be possible. If I try to "save" rather than "open" the attachments, I get an immediate "file input/output error" and that's that. I would be able to send you a copy of the "internet headers" from the message as it was received in FirstClass, as well as the headers of the copy of the message which I saved in Pegasus Mail when the message was being sent. Is this what you need? I'm not sure that this is something I would want to post in a public forum. Can I email them to you? Thanks again for your help. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2007-09-10 18:31 Message: Logged In: YES user_id=1123998 Originator: NO This appears to be a problem with header folding and unfolding resulting in the being possibly replaced by a which is shown as an 'invalid character' (the square symbol) by the mail client. Can you save the attachment and then open the saved file outside of FirstClass (perhaps after changing it's name or 'saving as' and providing a 'good' name)? I am unable to know what is at fault here without seeing the raw headers of the attachment part from the mail as sent and the mail as received from Mailman. It may be a Mailman issue, a cPanel issue or a FirstClass issue. Also, please see . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1792087&group_id=103 From noreply at sourceforge.net Thu Sep 20 10:47:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Sep 2007 01:47:27 -0700 Subject: [ mailman-Patches-1776178 ] Use inotify instead of polling in Runner.py Message-ID: Patches item #1776178, was opened at 2007-08-17 13:53 Message generated for change (Comment added) made by tsmetana You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1776178&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: Mailman 2.2 / 3.0 >Status: Open >Resolution: None Priority: 5 Private: No Submitted By: Tomas Smetana (tsmetana) Assigned to: Nobody/Anonymous (nobody) Summary: Use inotify instead of polling in Runner.py Initial Comment: Hi, the Mailman wakes up 7 times per second which is somehow resource unfriendly. This is caused by qrunners that poll for new files in queue directory. The proposed patch replaces polling in Runner.py with inotify which enables CPU to idle when possible. The patch requires python-inotify (http://pyinotify.sourceforge.net) to be installed. --ts ---------------------------------------------------------------------- >Comment By: Tomas Smetana (tsmetana) Date: 2007-09-20 10:47 Message: Logged In: YES user_id=1869522 Originator: YES Reopening: I have prepared new patches that were tested with Mailman 2 and look to be OK. Please consider incorporating the patches. File Added: mailman3-inotify.patch ---------------------------------------------------------------------- Comment By: Tomas Smetana (tsmetana) Date: 2007-08-24 10:07 Message: Logged In: YES user_id=1869522 Originator: YES The patches will make Mailman working but unstoppable. It looks to be a python's problem with handling signals in threads. I'm closing this ticket until the issues got solved. ---------------------------------------------------------------------- Comment By: Tomas Smetana (tsmetana) Date: 2007-08-21 10:04 Message: Logged In: YES user_id=1869522 Originator: YES I'm adding updated patch for Mailman 2.2 and a new patch for Mailman 3. I've moved the python-inotify parts in conditionals, so if inotify is not present in the system, everything should work as in the unpatched version. File Added: mailman3-inotify.patch ---------------------------------------------------------------------- Comment By: Tomas Smetana (tsmetana) Date: 2007-08-21 10:00 Message: Logged In: YES user_id=1869522 Originator: YES File Added: mailman-inotify.patch ---------------------------------------------------------------------- Comment By: Tomas Smetana (tsmetana) Date: 2007-08-17 14:36 Message: Logged In: YES user_id=1869522 Originator: YES Yes, you're right... I didn't realize that inotify is Linux specific. I will add a configure script option -- this should solve the Linux-only problem and make the python-inotify dependency optional. Also I will take a look at Mailman 3 and try to create a patch for it as well. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-08-17 14:16 Message: Logged In: YES user_id=12800 Originator: NO IIUC, inotify is a Linux-only thing so this would have to be optional. I haven't looked at the patch, but I would target this for Mailman 3 instead of 2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1776178&group_id=103 From noreply at sourceforge.net Thu Sep 20 10:48:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Sep 2007 01:48:08 -0700 Subject: [ mailman-Patches-1776178 ] Use inotify instead of polling in Runner.py Message-ID: Patches item #1776178, was opened at 2007-08-17 13:53 Message generated for change (Comment added) made by tsmetana You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1776178&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: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tomas Smetana (tsmetana) Assigned to: Nobody/Anonymous (nobody) Summary: Use inotify instead of polling in Runner.py Initial Comment: Hi, the Mailman wakes up 7 times per second which is somehow resource unfriendly. This is caused by qrunners that poll for new files in queue directory. The proposed patch replaces polling in Runner.py with inotify which enables CPU to idle when possible. The patch requires python-inotify (http://pyinotify.sourceforge.net) to be installed. --ts ---------------------------------------------------------------------- >Comment By: Tomas Smetana (tsmetana) Date: 2007-09-20 10:48 Message: Logged In: YES user_id=1869522 Originator: YES File Added: mailman-inotify.patch ---------------------------------------------------------------------- Comment By: Tomas Smetana (tsmetana) Date: 2007-09-20 10:47 Message: Logged In: YES user_id=1869522 Originator: YES Reopening: I have prepared new patches that were tested with Mailman 2 and look to be OK. Please consider incorporating the patches. File Added: mailman3-inotify.patch ---------------------------------------------------------------------- Comment By: Tomas Smetana (tsmetana) Date: 2007-08-24 10:07 Message: Logged In: YES user_id=1869522 Originator: YES The patches will make Mailman working but unstoppable. It looks to be a python's problem with handling signals in threads. I'm closing this ticket until the issues got solved. ---------------------------------------------------------------------- Comment By: Tomas Smetana (tsmetana) Date: 2007-08-21 10:04 Message: Logged In: YES user_id=1869522 Originator: YES I'm adding updated patch for Mailman 2.2 and a new patch for Mailman 3. I've moved the python-inotify parts in conditionals, so if inotify is not present in the system, everything should work as in the unpatched version. File Added: mailman3-inotify.patch ---------------------------------------------------------------------- Comment By: Tomas Smetana (tsmetana) Date: 2007-08-21 10:00 Message: Logged In: YES user_id=1869522 Originator: YES File Added: mailman-inotify.patch ---------------------------------------------------------------------- Comment By: Tomas Smetana (tsmetana) Date: 2007-08-17 14:36 Message: Logged In: YES user_id=1869522 Originator: YES Yes, you're right... I didn't realize that inotify is Linux specific. I will add a configure script option -- this should solve the Linux-only problem and make the python-inotify dependency optional. Also I will take a look at Mailman 3 and try to create a patch for it as well. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-08-17 14:16 Message: Logged In: YES user_id=12800 Originator: NO IIUC, inotify is a Linux-only thing so this would have to be optional. I haven't looked at the patch, but I would target this for Mailman 3 instead of 2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1776178&group_id=103 From noreply at sourceforge.net Thu Sep 20 13:14:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Sep 2007 04:14:54 -0700 Subject: [ mailman-Patches-1798683 ] SMTP authentication and TLS support Message-ID: Patches item #1798683, was opened at 2007-09-20 13: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=1798683&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: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tomas Smetana (tsmetana) Assigned to: Nobody/Anonymous (nobody) Summary: SMTP authentication and TLS support Initial Comment: Hi, here's a patch for Mailman 2.x that enables it using SMTP AUTH and TLS connection. This features might be useful on more paranoid SMTP servers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1798683&group_id=103 From noreply at sourceforge.net Wed Sep 26 08:02:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Sep 2007 23:02:14 -0700 Subject: [ mailman-Bugs-1802436 ] Multi-Multipart Message Message-ID: Bugs item #1802436, was opened at 2007-09-26 16:02 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=1802436&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 Private: No Submitted By: Lucanos (lucanos) Assigned to: Nobody/Anonymous (nobody) Summary: Multi-Multipart Message Initial Comment: When emails are relayed via the MailMan system, the multipart tags result in an extra part containing just the MailMan signature, which seems un-necessary. EXAMPLE: ------=_Part_26224_2463088.1190786011290 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [[ORIGINAL EMAIL MESSAGE]] ------=_Part_26224_2463088.1190786011290 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ [[MAILMAN LIST NAME]] [[MAILMAN LIST ADDRESS] http://[[MAILMAN URL]] ------=_Part_26224_2463088.1190786011290-- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1802436&group_id=103 From noreply at sourceforge.net Wed Sep 26 16:38:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Sep 2007 07:38:39 -0700 Subject: [ mailman-Bugs-1802436 ] Multi-Multipart Message Message-ID: Bugs item #1802436, was opened at 2007-09-25 23:02 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1802436&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 Private: No Submitted By: Lucanos (lucanos) Assigned to: Nobody/Anonymous (nobody) Summary: Multi-Multipart Message Initial Comment: When emails are relayed via the MailMan system, the multipart tags result in an extra part containing just the MailMan signature, which seems un-necessary. EXAMPLE: ------=_Part_26224_2463088.1190786011290 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [[ORIGINAL EMAIL MESSAGE]] ------=_Part_26224_2463088.1190786011290 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ [[MAILMAN LIST NAME]] [[MAILMAN LIST ADDRESS] http://[[MAILMAN URL]] ------=_Part_26224_2463088.1190786011290-- ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2007-09-26 07:38 Message: Logged In: YES user_id=1123998 Originator: NO Yes, it seems unnecessary, but it's not. See . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1802436&group_id=103 From noreply at sourceforge.net Thu Sep 27 16:02:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Sep 2007 07:02:03 -0700 Subject: [ mailman-Patches-1803606 ] FORGED_MUA_THEBAT_CS: The Bat! and Spamassassin Message-ID: Patches item #1803606, was opened at 2007-09-27 16:02 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=1803606&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: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Julian Ladisch (julianladisch) Assigned to: Nobody/Anonymous (nobody) Summary: FORGED_MUA_THEBAT_CS: The Bat! and Spamassassin Initial Comment: The mail user agent "The Bat!" creates header lines like this if there is some non-ascii character like a umlaut (?): X-Mailer: The Bat! (v2.00) Content-Type: text/plain; charset=ISO-8859-15 "The Bat!" never puts quotes around the charset. Mailman's Decorate.py changes this to: X-Mailer: The Bat! (v2.00) Content-Type: text/plain; charset="iso-8859-15" Spamassassin has a spam detection rule that triggeres if X-Mailer contains "The Bat!" and there are quotes around the charset. The rule is named FORGED_MUA_THEBAT_CS and is located in rules/20_ratware.cf http://svn.apache.org/repos/asf/spamassassin/tags/spamassassin_release_3_2_3/rules/20_ratware.cf My patch renames X-Mailer to X-X-Mailer. That prevents triggering the rule without information loss. I've tested the patch that applies to 2.1.7 and it works for me. I havn't tested the patch for trunk (8228). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1803606&group_id=103 From noreply at sourceforge.net Thu Sep 27 16:02:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Sep 2007 07:02:54 -0700 Subject: [ mailman-Patches-1803606 ] FORGED_MUA_THEBAT_CS: The Bat! and Spamassassin Message-ID: Patches item #1803606, was opened at 2007-09-27 16:02 Message generated for change (Comment added) made by julianladisch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1803606&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: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Julian Ladisch (julianladisch) Assigned to: Nobody/Anonymous (nobody) Summary: FORGED_MUA_THEBAT_CS: The Bat! and Spamassassin Initial Comment: The mail user agent "The Bat!" creates header lines like this if there is some non-ascii character like a umlaut (?): X-Mailer: The Bat! (v2.00) Content-Type: text/plain; charset=ISO-8859-15 "The Bat!" never puts quotes around the charset. Mailman's Decorate.py changes this to: X-Mailer: The Bat! (v2.00) Content-Type: text/plain; charset="iso-8859-15" Spamassassin has a spam detection rule that triggeres if X-Mailer contains "The Bat!" and there are quotes around the charset. The rule is named FORGED_MUA_THEBAT_CS and is located in rules/20_ratware.cf http://svn.apache.org/repos/asf/spamassassin/tags/spamassassin_release_3_2_3/rules/20_ratware.cf My patch renames X-Mailer to X-X-Mailer. That prevents triggering the rule without information loss. I've tested the patch that applies to 2.1.7 and it works for me. I havn't tested the patch for trunk (8228). ---------------------------------------------------------------------- >Comment By: Julian Ladisch (julianladisch) Date: 2007-09-27 16:02 Message: Logged In: YES user_id=561017 Originator: YES File Added: Decorate.py-8228.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1803606&group_id=103 From noreply at sourceforge.net Fri Sep 28 01:18:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Sep 2007 16:18:30 -0700 Subject: [ mailman-Patches-1803606 ] FORGED_MUA_THEBAT_CS: The Bat! and Spamassassin Message-ID: Patches item #1803606, was opened at 2007-09-27 07:02 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1803606&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: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Julian Ladisch (julianladisch) Assigned to: Nobody/Anonymous (nobody) Summary: FORGED_MUA_THEBAT_CS: The Bat! and Spamassassin Initial Comment: The mail user agent "The Bat!" creates header lines like this if there is some non-ascii character like a umlaut (?): X-Mailer: The Bat! (v2.00) Content-Type: text/plain; charset=ISO-8859-15 "The Bat!" never puts quotes around the charset. Mailman's Decorate.py changes this to: X-Mailer: The Bat! (v2.00) Content-Type: text/plain; charset="iso-8859-15" Spamassassin has a spam detection rule that triggeres if X-Mailer contains "The Bat!" and there are quotes around the charset. The rule is named FORGED_MUA_THEBAT_CS and is located in rules/20_ratware.cf http://svn.apache.org/repos/asf/spamassassin/tags/spamassassin_release_3_2_3/rules/20_ratware.cf My patch renames X-Mailer to X-X-Mailer. That prevents triggering the rule without information loss. I've tested the patch that applies to 2.1.7 and it works for me. I havn't tested the patch for trunk (8228). ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2007-09-27 16:18 Message: Logged In: YES user_id=1123998 Originator: NO If you really want to nullify this spamassassin test, why not just put score FORGED_MUA_THEBAT_CS 0 0 0 0 in the appropriate spamassassin user_prefs file? ---------------------------------------------------------------------- Comment By: Julian Ladisch (julianladisch) Date: 2007-09-27 07:02 Message: Logged In: YES user_id=561017 Originator: YES File Added: Decorate.py-8228.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1803606&group_id=103 From noreply at sourceforge.net Fri Sep 28 02:53:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Sep 2007 17:53:49 -0700 Subject: [ mailman-Patches-1803606 ] FORGED_MUA_THEBAT_CS: The Bat! and Spamassassin Message-ID: Patches item #1803606, was opened at 2007-09-27 16:02 Message generated for change (Comment added) made by julianladisch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1803606&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: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Julian Ladisch (julianladisch) Assigned to: Nobody/Anonymous (nobody) Summary: FORGED_MUA_THEBAT_CS: The Bat! and Spamassassin Initial Comment: The mail user agent "The Bat!" creates header lines like this if there is some non-ascii character like a umlaut (?): X-Mailer: The Bat! (v2.00) Content-Type: text/plain; charset=ISO-8859-15 "The Bat!" never puts quotes around the charset. Mailman's Decorate.py changes this to: X-Mailer: The Bat! (v2.00) Content-Type: text/plain; charset="iso-8859-15" Spamassassin has a spam detection rule that triggeres if X-Mailer contains "The Bat!" and there are quotes around the charset. The rule is named FORGED_MUA_THEBAT_CS and is located in rules/20_ratware.cf http://svn.apache.org/repos/asf/spamassassin/tags/spamassassin_release_3_2_3/rules/20_ratware.cf My patch renames X-Mailer to X-X-Mailer. That prevents triggering the rule without information loss. I've tested the patch that applies to 2.1.7 and it works for me. I havn't tested the patch for trunk (8228). ---------------------------------------------------------------------- >Comment By: Julian Ladisch (julianladisch) Date: 2007-09-28 02:53 Message: Logged In: YES user_id=561017 Originator: YES Mailman delivers the email to all subscribers of the mailing list. Spamassassin runs on the mail servers of the subscribers. I don't have access to the configuration of these mail servers, so I cannot nullify that spamassassin test. For discussing improvements to spamassassin regarding this bug please use http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5658 However, as many sites don't update spamassassin frequently we should consider patching Mailman as well. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2007-09-28 01:18 Message: Logged In: YES user_id=1123998 Originator: NO If you really want to nullify this spamassassin test, why not just put score FORGED_MUA_THEBAT_CS 0 0 0 0 in the appropriate spamassassin user_prefs file? ---------------------------------------------------------------------- Comment By: Julian Ladisch (julianladisch) Date: 2007-09-27 16:02 Message: Logged In: YES user_id=561017 Originator: YES File Added: Decorate.py-8228.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1803606&group_id=103 From noreply at sourceforge.net Fri Sep 28 13:21:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Sep 2007 04:21:17 -0700 Subject: [ mailman-Bugs-1804118 ] winmail.dat Message-ID: Bugs item #1804118, was opened at 2007-09-28 06:21 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=1804118&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 Private: No Submitted By: Terry K. Moore (guncalvert) Assigned to: Nobody/Anonymous (nobody) Summary: winmail.dat Initial Comment: The file winmail.dat is being sent as an attachment on my outgoing mail and I can't seem to be able to get rid of it. Is there a way to stop it from sending those? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1804118&group_id=103 From noreply at sourceforge.net Fri Sep 28 18:42:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Sep 2007 09:42:45 -0700 Subject: [ mailman-Bugs-1804118 ] winmail.dat Message-ID: Bugs item #1804118, was opened at 2007-09-28 04:21 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1804118&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: Invalid Priority: 5 Private: No Submitted By: Terry K. Moore (guncalvert) Assigned to: Nobody/Anonymous (nobody) Summary: winmail.dat Initial Comment: The file winmail.dat is being sent as an attachment on my outgoing mail and I can't seem to be able to get rid of it. Is there a way to stop it from sending those? ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2007-09-28 09:42 Message: Logged In: YES user_id=1123998 Originator: NO I don't see that this is a Mailman bug or even perhaps a Mailman issue, but if you're asking how the stop MS-Outlook from adding the winmail.dat attachment, there are many web resources to help with this. for some starting points, see and . If you're asking how to prevent Mailman from sending such attachments to a list, use Mailman's content filtering to remove them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1804118&group_id=103