Mailman 3 May 2008 - Mailman-coders

[ mailman-Bugs-1956393 ] List Options change of address accepts mailto:
by SourceForge.net May 2, 2008

May 2, 2008

Bugs item #1956393, was opened at 2008-05-02 12:16 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1956393&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: 2.1 (stable) Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: niall shaw (sgpostie) >Assigned to: Mark Sapiro (msapiro) Summary: List Options change of address accepts mailto: Initial Comment: One of my users changed their subscription address by copying and pasting in List Options, and accidentally included the mailto: protocol. While they received messages at their new address, they were not recognised as subscribers when attempting to send. Testing this, I find that the Mass Subscription page strips mailto: and subscribes the proper address. **The normal deletion tools fail to operate on the invalid address**: Membership list unsub checkbox; Mass Removal page; Command Line remove_members - all fail to remove an address with mailto: remove_members produces the following error for the example address mailto:testaddress@server: ----- Traceback (most recent call last): File "/usr/sbin/remove_members", line 186, in ? main() File "/usr/sbin/remove_members", line 176, in main admin_notif, userack) File "/usr/lib/mailman/Mailman/MailList.py", line 1014, in ApprovedDeleteMember self.removeMember(emailaddr) File "/usr/lib/mailman/Mailman/OldStyleMemberships.py", line 220, in removeMember self.__assertIsMember(member) File "/usr/lib/mailman/Mailman/OldStyleMemberships.py", line 113, in __assertIsMember raise Errors.NotAMemberError, member Mailman.Errors.NotAMemberError: testaddress@server ----- - indicating (I think) that the search function fails because it doesn't include mailto: as part of the address. There *is* a workaround: clone_member -r will delete the invalid address. (Using clone_member without -r successfully creates a new valid subscription, e.g. testaddress@server - but this then will be deleted by any of the above tools rather than "mailto:testaddress@server"!) However, the main problem here is that mailto: is accepted by the List Options page change of address mechanism. Hopefully it would not be too hard to adapt the filtering used on the Mass Subscription page? ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-05-02 14:37 Message: Logged In: YES user_id=1123998 Originator: NO Wow, is this a can of worms. Actually, mailto:user@example.com should be a valid email address although it should be quoted as "mailto:user"@example.com because it contains a colon. However, as you have observed, there are multiple problems with this in Mailman. Note that in addition to your clone_member workaround, the withlist method described at <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.013.htp> will also work to remove the address. Most of the command line tools don't work, because they use the Python email.Utils.parseaddr() function to parse the input into real name and address, and this returns various things depending on exactly how the address is presented. E.g. email.Utils.parseaddr('mailto:user@example.com') returns 'user(a)example.com' which is why mass subscribe "works", but email.Utils.parseaddr('<mailto:user@example.com>') returns 'mailto'. Also, MTAs get involved. In my test with Postfix, Mailman sent the confirmation to mailto:user@example.com with an envelope from list-bounces+mailto:user=example.com@example.net, and Postfix changed these to user(a)example.com and user=example.com(a)example.net respectively. If it weren't for this, the confirmation couldn't be received in the first place and the change couldn't be confirmed. Anyway, it needs to be fixed. Since there should not be any colon (or several other characters) in unquoted local parts, I'll check explicitly for that in Mailman.Utils.ValidateEmail(), which is used everywhere to validate email addresses. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1956393&group_…

1 0

[ mailman-Bugs-1956393 ] List Options change of address accepts mailto:
by SourceForge.net May 2, 2008

May 2, 2008

Bugs item #1956393, was opened at 2008-05-02 20:16 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=1956393&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Private: No Submitted By: niall shaw (sgpostie) Assigned to: Nobody/Anonymous (nobody) Summary: List Options change of address accepts mailto: Initial Comment: One of my users changed their subscription address by copying and pasting in List Options, and accidentally included the mailto: protocol. While they received messages at their new address, they were not recognised as subscribers when attempting to send. Testing this, I find that the Mass Subscription page strips mailto: and subscribes the proper address. **The normal deletion tools fail to operate on the invalid address**: Membership list unsub checkbox; Mass Removal page; Command Line remove_members - all fail to remove an address with mailto: remove_members produces the following error for the example address mailto:testaddress@server: ----- Traceback (most recent call last): File "/usr/sbin/remove_members", line 186, in ? main() File "/usr/sbin/remove_members", line 176, in main admin_notif, userack) File "/usr/lib/mailman/Mailman/MailList.py", line 1014, in ApprovedDeleteMember self.removeMember(emailaddr) File "/usr/lib/mailman/Mailman/OldStyleMemberships.py", line 220, in removeMember self.__assertIsMember(member) File "/usr/lib/mailman/Mailman/OldStyleMemberships.py", line 113, in __assertIsMember raise Errors.NotAMemberError, member Mailman.Errors.NotAMemberError: testaddress@server ----- - indicating (I think) that the search function fails because it doesn't include mailto: as part of the address. There *is* a workaround: clone_member -r will delete the invalid address. (Using clone_member without -r successfully creates a new valid subscription, e.g. testaddress@server - but this then will be deleted by any of the above tools rather than "mailto:testaddress@server"!) However, the main problem here is that mailto: is accepted by the List Options page change of address mechanism. Hopefully it would not be too hard to adapt the filtering used on the Mass Subscription page? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1956393&group_…

1 0

[ mailman-Patches-1955890 ] confirm subject changed externally, inbound to mailman
by SourceForge.net May 2, 2008

May 2, 2008

Patches item #1955890, was opened at 2008-05-01 23:10 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1955890&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steve (spm999) Assigned to: Nobody/Anonymous (nobody) Summary: confirm subject changed externally, inbound to mailman Initial Comment: We have an issue where due to (Aust.) Federal Govt. requirements (Don't ask == don't get me started...) all emails will typically have the text "[SEC=UNCLASSIFIED]" appended to the end of the Subject line. This breaks mailman confirm processing and the users get a mailman usage message back, instead of a successful confirm. Asking users to manually remove this is effectively impossible as the confirm emails will then be blocked within the users network. Sigh. I'm investigating a pre-mailman altermime like stripper in the MTA itself of and for this unwelcome appendage, but the following patch *appears* to work for us. Not yet gone live into production. Mailman v2.1.9 --- Mailman/Commands/cmd_confirm.py.ORG 2008-05-02 15:43:35.000000000 +1000 +++ Mailman/Commands/cmd_confirm.py 2008-05-02 15:43:44.000000000 +1000 @@ -37,7 +37,7 @@ def process(res, args): mlist = res.mlist - if len(args) <> 1: + if len(args) > 2: res.results.append(_('Usage:')) res.results.append(gethelp(mlist)) return STOP ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-05-02 06:47 Message: Logged In: YES user_id=1123998 Originator: NO Why not just set VERP_CONFIRMATIONS = Yes in mm_cfg.py? Then the subject of the message (which will be something like "Your confirmation is required...") is irrelevant in the reply because the From: which become the To: of the reply is "list-confirm+xxxxxxxxxxxx". The only requirement for this to work is that your MTA has to recognize that '+' is a suffix delimiter in the local part of the address. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1955890&group_…

1 0

[ mailman-Patches-1955890 ] confirm subject changed externally, inbound to mailman
by SourceForge.net May 2, 2008

May 2, 2008

Patches item #1955890, was opened at 2008-05-02 06:10 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=1955890&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steve (spm999) Assigned to: Nobody/Anonymous (nobody) Summary: confirm subject changed externally, inbound to mailman Initial Comment: We have an issue where due to (Aust.) Federal Govt. requirements (Don't ask == don't get me started...) all emails will typically have the text "[SEC=UNCLASSIFIED]" appended to the end of the Subject line. This breaks mailman confirm processing and the users get a mailman usage message back, instead of a successful confirm. Asking users to manually remove this is effectively impossible as the confirm emails will then be blocked within the users network. Sigh. I'm investigating a pre-mailman altermime like stripper in the MTA itself of and for this unwelcome appendage, but the following patch *appears* to work for us. Not yet gone live into production. Mailman v2.1.9 --- Mailman/Commands/cmd_confirm.py.ORG 2008-05-02 15:43:35.000000000 +1000 +++ Mailman/Commands/cmd_confirm.py 2008-05-02 15:43:44.000000000 +1000 @@ -37,7 +37,7 @@ def process(res, args): mlist = res.mlist - if len(args) <> 1: + if len(args) > 2: res.results.append(_('Usage:')) res.results.append(gethelp(mlist)) return STOP ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1955890&group_…

1 0