New submission from Toni Mueller <tonimuel...@users.sourceforge.net>:

email's usage of __setitem__ is highly counterintuitive to the point of being 
dangerous. The documented behaviour is (quote):


__setitem__(name, val)

    Add a header to the message with field name name and value val. The field 
is appended to the end of the message’s existing fields.

    Note that this does not overwrite or delete any existing header with the 
same name. If you want to ensure that the new header is the only one present in 
the message with field name name, delete the field first, e.g.:
...

(taken from http://docs.python.org/library/email.message.html )

The use case of *appending* a header of the same type (eg. a "Received:" 
header) should be performed by the add_header() method, or an extend_header() 
method, or something similar, and not by abusing the __setitem__ method. The 
current behaviour imho deviates extremely from the behaviour of similar 
libraries in all other programming languages that I'm aware of, and from the 
standard dict functionality, too. It makes it much too easy to have duplicate 
headers, esp., duplicate "To:" headers, resulting in mailbombing and 
information leakage. For the potential damage, this property of the library is 
highly under-advertised.

A side effect appears to be that trying to have your message headers set up in 
a unique fashion, probably the most frequent use case, one has to make sure to 
use each operator only once, or "decorate" everything with a del msg[myheader], 
as the operation is not idempotent.

----------
messages: 136276
nosy: tonimueller
priority: normal
severity: normal
status: open
title: email's use of __setitem__ is highly counterintuitive
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12111>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to