The code in the attached parse_bug.py file when run with Python 3.5, 3.6 or 3.7 throws AttributeError with this traceback:

```
Traceback (most recent call last):
  File "parse_bug.py", line 9, in <module>
    """)
  File "/usr/local/lib/python3.7/email/parser.py", line 124, in parsebytes
    return self.parser.parsestr(text, headersonly)
  File "/usr/local/lib/python3.7/email/parser.py", line 68, in parsestr
    return self.parse(StringIO(text), headersonly=headersonly)
  File "/usr/local/lib/python3.7/email/parser.py", line 58, in parse
    return feedparser.close()
  File "/usr/local/lib/python3.7/email/feedparser.py", line 187, in close
    self._call_parse()
  File "/usr/local/lib/python3.7/email/feedparser.py", line 180, in _call_parse
    self._parse()
  File "/usr/local/lib/python3.7/email/feedparser.py", line 323, in _parsegen
    if (self._cur.get('content-transfer-encoding', '8bit').lower()
AttributeError: 'Header' object has no attribute 'lower'
```

The triggering condition appears to be the Content-Transfer-Encoding: header with a non-ascii character in the headers of a multipart part.

The parser should probably throw email.errors.HeaderParseError with a MalformedHeaderDefect in this case rather than AttributeError.

While arguably code should defend against unanticipated exceptions, the fact that such an exception can be thrown while parsing an arbitrary message could be considered a security issue.

Hi Mark,

Do you want to submit a PR for this issue?

Not a security issue, no.  This isn't C where a stack overflow can give an attacker a vector for injecting arbitrary code.

Per the Parser contract ("raise no exceptions, only register defects"), this should, as you say, register a defect (email.errors.InvalidMultipartContentTransferEncodingDefect) and assume a CTE of 7bit for the rest of the parsing.  The problem here is that the feedparser is running into the "hack" I put in place in python3.2 for dealing with invalid binary data in headers (which is to turn it into a Header with charset unknown-8bit).  That works most of the time, but in cases like this it breaks down :(

Note that the new API (policy=default and friends) handles this without error.

I do intend to submit a PR. I haven't yet worked it out though.

This is a dupe of https://bugs.python.org/issue30835, which has an attached PR.

I have verified the provided test case is fixed by the PR for bpo-30835.

The PR for bpo-30835 changes code in a different source file. I suggest adopting both PRs so that future changes don't accidentally reintroduce either bug.

I am not sure which 2nd PR are we talking about here?

The reported exception stems from Lib/email/feedparser.py#L323 and same is fixed in PR (https://github.com/python/cpython/pull/13598) for bpo-30835.

My mistake for responding to the wrong issue.