[issue10839] email module should not allow some header field repetitions

R. David Murray added the comment: I've committed Berker's patch from #27331, and I'm about to take the new email API out of provisional status. Barry is committed to not changing this behavior in 2.7 and I agree. In any case 2.7 doesn't differentiate between headers being added by the user

[issue10839] email module should not allow some header field repetitions

R. David Murray added the comment: In the new API there's no real reason to use the old MIME classes. If you want to add the keyword I have no objection, though. I started a documentation revision last year but haven't had time to get back to it. Hopefully I'll dust it off Real Soon Now.

[issue10839] email module should not allow some header field repetitions

Berker Peksag added the comment: > Right, that's what I meant by "plumb". :) Sorry, apparently I can't read in the mornings :) I have just opened issue 27331 to implement this idea. -- ___ Python tracker

[issue10839] email module should not allow some header field repetitions

Barry A. Warsaw added the comment: On Jun 13, 2016, at 08:34 AM, Berker Peksag wrote: >Berker Peksag added the comment: > >> I think we just need to plumb a `policy` argument through to the ultimate >> base class, email.message.Message > >That's already possible:

[issue10839] email module should not allow some header field repetitions

Berker Peksag added the comment: > I think we just need to plumb a `policy` argument through to the ultimate base > class, email.message.Message That's already possible: https://docs.python.org/dev/library/email.message.html#email.message.Message It would be nice to be able to customize

[issue10839] email module should not allow some header field repetitions

Barry A. Warsaw added the comment: On Jun 13, 2016, at 06:38 AM, Berker Peksag wrote: >I don't know if it's a good idea or API but can we add a 'policy' keyword >argument to email.mime.base.MIMEBase? Right now, this is the only way to >change the default policy without using high level

[issue10839] email module should not allow some header field repetitions

Berker Peksag added the comment: I don't think a new API is needed. But we need to promote the policy keyword better in docs. See https://twitter.com/aksiksi/status/741769504817045508 for an example of confusion. I don't know if it's a good idea or API but can we add a 'policy' keyword

[issue10839] email module should not allow some header field repetitions

Barry A. Warsaw added the comment: On Jun 12, 2016, at 09:19 PM, Raymond Hettinger wrote: >Would you consider raising an exception at least for the case of a "To:" >header or perhaps a warning or someother failsafe. No, not for compat32 policy. Seriously, I do not want to change the semantics

[issue10839] email module should not allow some header field repetitions

Barry A. Warsaw added the comment: On Jun 13, 2016, at 12:09 AM, Martin Panter wrote: >I think I would support deprecating the __setitem__() etc methods, perhaps >with a cleanup of the alternatives, e.g. add remove_all(). Also, >__getitem__() is equivalent to get(), which does not raise

[issue10839] email module should not allow some header field repetitions

Martin Panter added the comment: There are already the makings of an alternative API: https://docs.python.org/3.6/library/email.message.html#email.message.Message.add_header There is also replace_header(), but it only replaces the _first_ header field, and leaves later ones untouched. However

[issue10839] email module should not allow some header field repetitions

Raymond Hettinger added the comment: Would you consider raising an exception at least for the case of a "To:" header or perhaps a warning or someother failsafe. Using __setitem__ for appending instead of replacement is surprising and in the case of LetsEncrypt was a small disaster. There is

[issue10839] email module should not allow some header field repetitions

Barry A. Warsaw added the comment: On Jun 11, 2016, at 09:25 PM, Raymond Hettinger wrote: >I think we should consider this as an API design bug and backport the fix. No, it's deliberate, required, and expected in some cases as RDM explains. Certainly for compat32 policy, this can't change.

[issue10839] email module should not allow some header field repetitions

Berker Peksag added the comment: The API in Python 3 is very different and I'm not sure we can backport the expected behavior without breaking other people's code (unless we treat this as a security issue). Here is a naive backport for 2.7. Known test failures: test_get_all,

[issue10839] email module should not allow some header field repetitions

Raymond Hettinger added the comment: I think we should consider this as an API design bug and backport the fix. This seems to be the exact cause of this week's email address leak at LetsEncrypt: *

[issue10839] email module should not allow some header field repetitions

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset d7881a371c41 by R David Murray in branch 'default': #10839: raise an error on add of duplicate unique headers in new email policies http://hg.python.org/cpython/rev/d7881a371c41 -- nosy: +python-dev

[issue10839] email module should not allow some header field repetitions

R. David Murray rdmur...@bitdance.com added the comment: Committed. It is almost never the right thing to do to allow duplicates of unique headers, but an application that does need it can create a policy subclass and override the header_max_count method. -- resolution: - fixed

[issue10839] email module should not allow some header field repetitions

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 08857f4e9709 by R David Murray in branch 'default': #10839: add new test file that was omitted from checkin http://hg.python.org/cpython/rev/08857f4e9709 -- ___ Python

[issue10839] email module should not allow some header field repetitions

Changes by R. David Murray rdmur...@bitdance.com: -- components: +email -Library (Lib) nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10839 ___

[issue10839] email module should not allow some header field repetitions

R. David Murray rdmur...@bitdance.com added the comment: My original fix for this for email6 got lost in a refactoring. Here is a patch that fixes it in the code I recently checked in. It may not cover all the headers that should be unique, since I haven't implemented parsers for all

[issue10839] email module should not allow some header field repetitions

R. David Murray rdmur...@bitdance.com added the comment: Regardless of what anybody thinks about the design, it is what it is and can't be changed for backward compatibility reasons. The best we can do is reject creating duplicate headers for headers that may only appear once. That feature

[issue10839] email module should not allow some header field repetitions

kxroberto kxrobe...@users.sourceforge.net added the comment: I think really ill/strange is that kind of item _assignments_ do _add_ multiple. If msg[field] = xywould just add-first/replace-frist , and only msg.add_/.append(field, xy) would add multiples that would be clear and

[issue10839] email module should not allow some header field repetitions

New submission from Adrien Saladin adrien.sala...@gmail.com: Hi, The following script shows two problems with email.mime.text.MIMEText: - first the use of msg['To'] seems confusing because its dictionnary-like syntax made me think it acts as a set or replace, but in fact is working as a

[issue10839] email module should not allow some header field repetitions

Changes by Adrien Saladin adrien.sala...@gmail.com: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10839 ___ ___

[issue10839] email module should not allow some header field repetitions

Changes by Georg Brandl ge...@python.org: -- assignee: - r.david.murray nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10839 ___

[issue10839] email module should not allow some header field repetitions

R. David Murray rdmur...@bitdance.com added the comment: The behaviour you observe is by design, and documented. The email package needs to be able to handle RFC-invalid input, which includes messages with multiple instances of fields that are supposed to be singletons. It also needs to