List Options change of address accepts mailto:

[Sgpostie]

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?

[http://sourceforge.net/tracker/index.php?func=detail&aid=1956393&group_id=103&atid=100103]

[Mark Sapiro (msapiro)]

Originator: NO

Wow, is this a can of worms.

Actually, mailto:<email address hidden> should be a valid email address although
it should be quoted as "mailto:<email address hidden> 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:<email address hidden>')
returns '<email address hidden>' which is why mass subscribe "works", but
email.Utils.parseaddr('<mailto:<email address hidden>>') returns 'mailto'.

Also, MTAs get involved. In my test with Postfix, Mailman sent the
confirmation to mailto:<email address hidden> with an envelope from
list-bounces+mailto:<email address hidden>, and Postfix changed these
to <email address hidden> and <email address hidden> 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.

[Mark Sapiro (msapiro)]

This was actually fixed in 2.1.11.