Mailman-coders May 2008

mailman-coders@python.org

1 participants
23 discussions

[ mailman-Bugs-1956393 ] List Options change of address accepts mailto:

by SourceForge.net

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_…

12 years, 11 months

[ mailman-Patches-1955890 ] confirm subject changed externally, inbound to mailman

by SourceForge.net

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_…

12 years, 11 months

[ mailman-Patches-1955890 ] confirm subject changed externally, inbound to mailman

by SourceForge.net

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_…

12 years, 11 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders May 2008