Mailman 3 March 2008 - Mailman-coders

[ mailman-Patches-1906479 ] Add option for only munging Reply-To if it is not there
by SourceForge.net 03 Mar '08

03 Mar '08

Patches item #1906479, was opened at 2008-03-03 11:45 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Knut Auvor Grythe (auvor) Assigned to: Nobody/Anonymous (nobody) Summary: Add option for only munging Reply-To if it is not there Initial Comment: As I know a lot of you developers agree, Reply-To: header munging is not very nice. However, it appears to be a necessary evil sometimes. My biggest problem with Reply-To: header munging is that there is no way for a poster to direct replies off-list. Any attempt to do so will fail completely because MUAs obey the Reply-To: header, and the users don't notice. Ironically, these users are often the ones who made the munging necessary in the first place. However, I believe there is a solution to this problem. How about only adding a Reply-To: header only if one did not previously exist? This way, headers will be munged in the normal case, but if someone adds their own Reply-To: header for some reason, their value will be kept. Naturally, this behaviour should be optional, since it alters the behaviour of the lists. I have attached a patch which enables this functionality. The patch is against 2.1.9, but seems to apply on 2.1.10b1 without complaining. PS: This patch slightly changes the order in which munging is done, causing mlist.reply_to_address to be appended instead of prepended to the original Reply-To: header. I didn't consider this a problem, as it makes the behaviour if "This list" and "Explicit address" consistent. I also feel it made the code more straight-forward to read. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 12:37 Message: Logged In: YES user_id=1123998 Originator: NO Consider that user(a)example.com configures her MUA to add a Reply-To: user(a)example.com because when configuring the MUA, she was asked where replies should be sent and didn't realize this was optional or for whatever reason answered user(a)example.com. Consider that userb(a)example.com sets all his MUAs to generate Reply-To: userb(a)example.net because thats where he wants to read his mail regardless of where the original was sent from. How does your patch distinguish these cases from the one where the poster sets an explicit Reply-To: for this message only? The whole idea of reply-to munging is the notion that the list knows better than the poster where replies should go. If you want the poster to be able to determine this, don't mung the reply-to. -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&group_…

1 0

[ mailman-Patches-1906479 ] Add option for only munging Reply-To if it is not there
by SourceForge.net 03 Mar '08

03 Mar '08

Patches item #1906479, was opened at 2008-03-03 20:45 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=1906479&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Knut Auvor Grythe (auvor) Assigned to: Nobody/Anonymous (nobody) Summary: Add option for only munging Reply-To if it is not there Initial Comment: As I know a lot of you developers agree, Reply-To: header munging is not very nice. However, it appears to be a necessary evil sometimes. My biggest problem with Reply-To: header munging is that there is no way for a poster to direct replies off-list. Any attempt to do so will fail completely because MUAs obey the Reply-To: header, and the users don't notice. Ironically, these users are often the ones who made the munging necessary in the first place. However, I believe there is a solution to this problem. How about only adding a Reply-To: header only if one did not previously exist? This way, headers will be munged in the normal case, but if someone adds their own Reply-To: header for some reason, their value will be kept. Naturally, this behaviour should be optional, since it alters the behaviour of the lists. I have attached a patch which enables this functionality. The patch is against 2.1.9, but seems to apply on 2.1.10b1 without complaining. PS: This patch slightly changes the order in which munging is done, causing mlist.reply_to_address to be appended instead of prepended to the original Reply-To: header. I didn't consider this a problem, as it makes the behaviour if "This list" and "Explicit address" consistent. I also feel it made the code more straight-forward to read. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906479&group_…

1 0

[ mailman-Bugs-1906368 ] newlist: preferred_language not put into available_languages
by SourceForge.net 03 Mar '08

03 Mar '08

Bugs item #1906368, was opened at 2008-03-03 17:20 Message generated for change (Comment added) made by porridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1906368&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line scripts Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Marcin Owsiany (porridge) Assigned to: Mark Sapiro (msapiro) Summary: newlist: preferred_language not put into available_languages Initial Comment: When I run newlist with -l pl, then preferred_language does get set to 'pl', but available_languages is set to just ['en']. This causes two problems for me: - editing the default language on the language properties page gets tricky (you need to apply the settings twice, going through a page in english). - the installation scripts logic in the debian package reads available_languages to find out which language message files to install. Not having the preferred language in the available list means I will have to jump through some extra tricky hoops to get it working properly. Also, the comment in the config file does say that the default language should be in the available languages list, so I guess some assumptions are made in other parts of the codebase, which will cause undesired behavior. I guess the best way to fix this is to create a proper mutator method which will contain some logic to also update the available_languages property if need be. ---------------------------------------------------------------------- >Comment By: Marcin Owsiany (porridge) Date: 2008-03-03 19:45 Message: Logged In: YES user_id=1349753 Originator: YES Thanks for the patch and the quick response. This is really impressive! My problem with the debian installation scripts is somewhat complicated. What they do on install/upgrade, is first issue an interactive question for the list of languages to install, and then they automagically add to that list any languages that were not given, but are used by the existing mailing lists. This works fine for most users, but for me it would require some configuration preseeding, when building a machine with a pre-existing /var/lib/mailman (e.g. disaster recovery). Luckily, with your patch it should just do the right thing for me now. thanks again! ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 18:48 Message: Logged In: YES user_id=1123998 Originator: NO This is a bug in newlist fixed by the attached patch which will be in Mailman 2.1.10. The patch will add the selected language to available_languages if it is other than the server default language. As far as the Debian installation scripts logic is concerned, this is not something that the Mailman project has any control over, but I must not understand correctly in any case. It seems that you are saying that the package will not install any templates or message catalogs for languages that are not listed in available_languages of the existing lists, but this would result in a new installation containg support for only those languages listed as available for the packaged site list if that, so you must be saying something else. File Added: newlist.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1906368&group_…

1 0

[ mailman-Bugs-1906368 ] newlist: preferred_language not put into available_languages
by SourceForge.net 03 Mar '08

03 Mar '08

Bugs item #1906368, was opened at 2008-03-03 08:20 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1906368&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line scripts Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Marcin Owsiany (porridge) >Assigned to: Mark Sapiro (msapiro) Summary: newlist: preferred_language not put into available_languages Initial Comment: When I run newlist with -l pl, then preferred_language does get set to 'pl', but available_languages is set to just ['en']. This causes two problems for me: - editing the default language on the language properties page gets tricky (you need to apply the settings twice, going through a page in english). - the installation scripts logic in the debian package reads available_languages to find out which language message files to install. Not having the preferred language in the available list means I will have to jump through some extra tricky hoops to get it working properly. Also, the comment in the config file does say that the default language should be in the available languages list, so I guess some assumptions are made in other parts of the codebase, which will cause undesired behavior. I guess the best way to fix this is to create a proper mutator method which will contain some logic to also update the available_languages property if need be. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-03 09:48 Message: Logged In: YES user_id=1123998 Originator: NO This is a bug in newlist fixed by the attached patch which will be in Mailman 2.1.10. The patch will add the selected language to available_languages if it is other than the server default language. As far as the Debian installation scripts logic is concerned, this is not something that the Mailman project has any control over, but I must not understand correctly in any case. It seems that you are saying that the package will not install any templates or message catalogs for languages that are not listed in available_languages of the existing lists, but this would result in a new installation containg support for only those languages listed as available for the packaged site list if that, so you must be saying something else. File Added: newlist.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1906368&group_…

1 0

[ mailman-Patches-1906265 ] Make all outgoing mails RFC 3834 compliant
by SourceForge.net 03 Mar '08

03 Mar '08

Patches item #1906265, was opened at 2008-03-03 08:35 Message generated for change (Comment added) made by jimpop You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906265&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lars K�ller (lkoeller) Assigned to: Nobody/Anonymous (nobody) Summary: Make all outgoing mails RFC 3834 compliant Initial Comment: Hi, please make all outgoing mail RFC 3834 compliant, to help reasonable processing in an RFC 3834 compliant MTA. Especially the vacation/autoreply functions of all up to date (e.g. SUN JSMS, Sophos PMX) mail servers respect these header tags and helps keeping the list admin free of managing dump reply mails. Details: http://www.ietf.org/rfc/rfc3834.txt Thanks! ---------------------------------------------------------------------- Comment By: Jim Popovitch (jimpop) Date: 2008-03-03 11:35 Message: Logged In: YES user_id=3142 Originator: NO Care to provide any specifics on just what exactly it is that you deem non-compliant? It's been a while since this debate has seen the light of day.... come prepared. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906265&group_…

1 0

[ mailman-Bugs-1906368 ] newlist: preferred_language not put into available_languages
by SourceForge.net 03 Mar '08

03 Mar '08

Bugs item #1906368, was opened at 2008-03-03 17:20 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=1906368&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line scripts Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marcin Owsiany (porridge) Assigned to: Nobody/Anonymous (nobody) Summary: newlist: preferred_language not put into available_languages Initial Comment: When I run newlist with -l pl, then preferred_language does get set to 'pl', but available_languages is set to just ['en']. This causes two problems for me: - editing the default language on the language properties page gets tricky (you need to apply the settings twice, going through a page in english). - the installation scripts logic in the debian package reads available_languages to find out which language message files to install. Not having the preferred language in the available list means I will have to jump through some extra tricky hoops to get it working properly. Also, the comment in the config file does say that the default language should be in the available languages list, so I guess some assumptions are made in other parts of the codebase, which will cause undesired behavior. I guess the best way to fix this is to create a proper mutator method which will contain some logic to also update the available_languages property if need be. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1906368&group_…

1 0

[ mailman-Patches-1906265 ] Make all outgoing mails RFC 3834 compliant
by SourceForge.net 03 Mar '08

03 Mar '08

Patches item #1906265, was opened at 2008-03-03 14:35 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=1906265&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lars K�ller (lkoeller) Assigned to: Nobody/Anonymous (nobody) Summary: Make all outgoing mails RFC 3834 compliant Initial Comment: Hi, please make all outgoing mail RFC 3834 compliant, to help reasonable processing in an RFC 3834 compliant MTA. Especially the vacation/autoreply functions of all up to date (e.g. SUN JSMS, Sophos PMX) mail servers respect these header tags and helps keeping the list admin free of managing dump reply mails. Details: http://www.ietf.org/rfc/rfc3834.txt Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1906265&group_…

1 0

[ mailman-Patches-1463918 ] Make password mailing RFC 3834 compliant
by SourceForge.net 03 Mar '08

03 Mar '08

Patches item #1463918, was opened at 2006-04-04 02:24 Message generated for change (Comment added) made by lkoeller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1463918&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kyle VanderBeek (kylev) Assigned to: Nobody/Anonymous (nobody) Summary: Make password mailing RFC 3834 compliant Initial Comment: RFC 3834 specifies that messages generated automatically by periodic automatic jobs should contain an Auto-Submitted header with a 'auto-generated' value; a 1-line patch does this for the cron'ed month membership reminder. This helps avoid loops and potential "sorcerers apprentice mode" when hitting well mannered vaction programs that recognize RFC 3834 headers. There is probably more work to do in mailman related to this RFC, as well. ---------------------------------------------------------------------- Comment By: Lars K�ller (lkoeller) Date: 2008-03-03 14:27 Message: Logged In: YES user_id=412469 Originator: NO Absolutely usefull feature! Should be implemented as soon as possible!! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1463918&group_…

1 0

[ mailman-Bugs-1904737 ] ban_list entry breaks bulk member import
by SourceForge.net 03 Mar '08

03 Mar '08

Bugs item #1904737, was opened at 2008-02-29 16:14 Message generated for change (Comment added) made by wlanguy2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1904737&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line scripts Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Lars Köller (wlanguy2) Assigned to: Mark Sapiro (msapiro) Summary: ban_list entry breaks bulk member import Initial Comment: Mailman 2.1.9 (python 2.4.4) on Solaris 8 SPARC: When an email address, e.g. dummy(a)example.com is inserted into the ban_list and the same member is tried to become a regular member, an error is triggered. The is really critical, cause automatically generated bulk imports fail. echo "dummy(a)example.com" | /usr/local/mailman/current/fhbi/bin/add_members -a n -w n -r - verteiler-zv Traceback (most recent call last): File "/usr/local/mailman/current/fhbi/bin/add_members", line 255, in ? main() File "/usr/local/mailman/current/fhbi/bin/add_members", line 235, in main addall(mlist, nmembers, 0, send_welcome_msg, s) File "/usr/local/mailman/current/fhbi/bin/add_members", line 135, in addall mlist.ApprovedAddMember(userdesc, ack, 0) File "/usr/localhost/mailman/current/fhbi/Mailman/MailList.py", line 958, in ApprovedAddMember raise Errors.MembershipIsBanned, pattern Mailman.Errors.MembershipIsBanned: dummy(a)example.com Please fix as fast as possible. many thanks and best regards Lars ---------------------------------------------------------------------- >Comment By: Lars Köller (wlanguy2) Date: 2008-03-03 09:01 Message: Logged In: YES user_id=2003250 Originator: YES Hi "mschapiro" :-) many thanks for the fast delivered fix! Best regards Lars ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-02-29 18:35 Message: Logged In: YES user_id=1123998 Originator: NO Fixed by the attached patch which also fixes sync_members and clone_member. File Added: patch.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1904737&group_…

1 0