[Mailman-Users] Removing illegal character user names

Mark Sapiro msapiro at value.net
Mon Mar 12 01:28:54 CET 2007

Dragon wrote:

>Mark Sapiro sent the message below at 12:41 PM 3/11/2007:
>>It's as I suspected. The various input tags on the Membership list look
>><INPUT name="user at example.com_unsub" type="CHECKBOX" value="off" >
>>where user at example.com is the email address. Clearly, if the address
>>contains double quotes, the field name gets truncated or garbled, so
>>it isn't possible to change anything for this member from the
>>Membership list page..
>---------------- End original message. ---------------------
>Which is valid, and proper HTML usage, all parameters in any HTML tag 
>should be enclosed in quotes. It is mandatory in XHTML.

I never meant to imply that this was not proper usage. I only quoted
the input tag in order to show that the email address was part of a
field name.

>So how do you deal with this?
>Quite simply by escaping any non alpha-numeric character with either 
>its symbolic or numeric code. It is always good practice in dealing 
>with any sort of CGI or user generated data to ensure that just such 
>situations or worse will not occur.
>If there is a Python module out there for escaping HTML strings, it 
>seems like it would be a fairly simple task to apply the escape 
>function while generating the output to the page.

That's half (or less) of the solution. The other part is recognizing
the input field names with escaped characters. The change to the
admin.py script is not that difficult. In case anyone is interested, I
have attached a patch.

I am reluctant to commit the patch for a few reasons. It breaks a
couple of screen scraping mailman-subscribers.py scripts which can be
fixed, but what else does it break?

Also, I'm not sure that there's really a problem needing to be fixed.
RFC 2821 allows quoted local-parts in email addresses, but are there
any in practice? If someone inadvertently subscribes an address with
quotes as the OP did, the bad address can be easily removed via
mass-remove even though not by the unsub checkbox.

I understand the point about good practice, and we do try to validate
user input in Mailman to avoid possible XSS attacks via the web
interface. What we're dealing with here are syntactically validated
email addresses so the really nasty stuff has already been caught.

Still, I'm interested in feedback from anyone who has an opinion about

Mark Sapiro <msapiro at value.net>       The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: admin.patch.txt
Url: http://mail.python.org/pipermail/mailman-users/attachments/20070311/3f0cd900/attachment.txt 

More information about the Mailman-Users mailing list