R. David Murray <rdmur...@bitdance.com> added the comment:
I don't believe either the example that other mailers reject or the one that
they accept are in fact RFC compliant. Encoded words are not supposed to occur
in (structured) MIME headers. The behavior observed is a consequence of all
headers, whether structured or unstructured, being treated as if they were
unstructured by Header.
(There's a different problem in Python3 with this example, but I'll deal with
that in a separate issue.)
What we have here is primarily a documentation bug. The way to generate the
correct (RFC compliant) header is as follows:
>>> m.add_header('Content-Disposition', 'attachment',
... filename=('iso-8859-1', '', 'Fußballer_sind_klug.ppt'))
>>> str(m)
'Content-Disposition: attachment;
filename*="iso-8859-1\'\'Fu%DFballer_sind_klug.ppt"\n\n'
I will add the explanation and this example to the docs. In addition, in 3.2 I
will disallow non-ASCII parameter values unless they are specified in a three
element tuple as in the example above. That will still leave some other places
where structured headers are inappropriately encoded by Header (eg: addresses
with non-ASCII names), but dealing with that is a somewhat deeper problem.
----------
title: Email.Header encodes non-ASCII content incorrectly -> email.Header (via
add_header) encodes non-ASCII content incorrectly
type: feature request -> behavior
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1078919>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
