This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tonimueller
Recipients tonimueller
Date 2011-05-19.11:37:21
SpamBayes Score 1.2419267e-08
Marked as misclassified No
Message-id <>
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 )

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.
Date User Action Args
2011-05-19 11:37:22tonimuellersetrecipients: + tonimueller
2011-05-19 11:37:22tonimuellersetmessageid: <>
2011-05-19 11:37:22tonimuellerlinkissue12111 messages
2011-05-19 11:37:21tonimuellercreate