[issue5871] email.header.Header too lax with embeded newlines

R. David Murray added the comment: Ah, I should clarify. A sensible web application should be dealing with any multiline input it allows by turning it into a newline-less single line before using it as a subject, so the probability that there are exploitable applications out there is, I thin

[issue5871] email.header.Header too lax with embeded newlines

R. David Murray added the comment: Well, imagine a web form that has a 'subject' text entry field, and the application does Message['Subject'] = subject_from_form as it builds a Message to hand off to smtp.sendmail. If the application didn't sanitize the subject for newlines (and as a progra

[issue5871] email.header.Header too lax with embeded newlines

Barry A. Warsaw added the comment: I'm inclined not to support backporting to Python 2.6. It seems like a fairly rare and narrow hole for security problem, because it would require a program to add the bogus header explicitly, as opposed to getting it after parsing some data. To me, that sm

[issue5871] email.header.Header too lax with embeded newlines

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue5871] email.header.Header too lax with embeded newlines

R. David Murray added the comment: Receiving no negative votes :), I've committed this to py3k in r87873, 3.1 in r87874, and 2.7 in r87875. Barry, Martin, do you think this should be backported as a security fix? I'm thinking it should be. -- nosy: +loewis resolution: -> fixed stag

[issue5871] email.header.Header too lax with embeded newlines

R. David Murray added the comment: I've considered this a bit more deeply, and it turns out to be simpler to fix than I originally thought, assuming the fix is acceptable. When a message is parsed we obviously wind up with headers that don't have any embedding issues. So, if we check for emb

[issue5871] email.header.Header too lax with embeded newlines

Changes by R. David Murray : -- keywords: -easy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue5871] email.header.Header too lax with embeded newlines

R. David Murray added the comment: Re __getitem__: yes, the email package allows you to work with messages that are *not* RFC conformant (which you do encounter when processing actual email :), and this is an important feature. The plan in email6 is to detect and report additional RFC violat

[issue5871] email.header.Header too lax with embeded newlines

R. David Murray added the comment: Yeah, after I posted that suggestion it occurred to me that the newline stuff *is* embedded in the way email5 works, but I hadn't gotten back here to post a followup yet. I don't like it, but it is what it is. (I believe the theory is to preserve the forma

[issue5871] email.header.Header too lax with embeded newlines

Ray.Allen added the comment: Besides, not only the header value, but also the header name can only be printable ascii characters according to RFC2822: "A field name MUST be composed of printable US-ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except co

[issue5871] email.header.Header too lax with embeded newlines

Ville Lindholm added the comment: I tried doing a naive implementation (just checking for \n or \r in the argument to Header) but that breaks a lot of unit tests. For example the test message msg_16.txt contains a header like this: Received: from cougar.noc.ucla.edu (cougar.noc.ucla.edu [169.

[issue5871] email.header.Header too lax with embeded newlines

Terry J. Reedy added the comment: Given this "The email package attempts to be as RFC-compliant as possible," and your reading, I agree this is a backport-worth bug. This is the "prohibition in the docs" I was looking for. -- ___ Python tracker

[issue5871] email.header.Header too lax with embeded newlines

R. David Murray added the comment: Yeah, it's a good question whether or not this is enough of a behavior change that the fix can't be backported. On the other hand, this is definitely a bug (the RFCs specifiy that header values may not contain newlines or carriage returns), so at the moment

[issue5871] email.header.Header too lax with embeded newlines

Terry J. Reedy added the comment: My apologies for misunderstanding. Feature removal requests are sufficiently rare that I thought you were posting a mockup of what you wanted to be able to do, as many others have done. So we definitely agree on that example. I changed the title to be a littl