email/Generator.py: Incorrect header output

[mjepronk]

BPO	826756
Nosy	@warsaw

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/warsaw'
closed_at = <Date 2006-03-30.07:52:38.000>
created_at = <Date 2003-10-20.10:23:42.000>
labels = ['invalid', 'library']
title = 'email/Generator.py: Incorrect header output'
updated_at = <Date 2006-03-30.07:52:38.000>
user = 'https://bugs.python.org/mjepronk'

bugs.python.org fields:

activity = <Date 2006-03-30.07:52:38.000>
actor = 'bbaetz'
assignee = 'barry'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2003-10-20.10:23:42.000>
creator = 'mjepronk'
dependencies = []
files = []
hgrepos = []
issue_num = 826756
keywords = []
message_count = 3.0
messages = ['18691', '18692', '18693']
nosy_count = 3.0
nosy_names = ['barry', 'mjepronk', 'bbaetz']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue826756'
versions = ['Python 2.3']

[mjepronk]

I've found a small bug when using the email/Parser.py
classes. When there is a long "Subject" header, it will
be wrapped to multiple lines, which are preceded by a
tab. This is undesired behaviour, because e-mail
clients show this tab in the subject. Especially,
Mozilla for Windows shows a strange square symbol. The
following code in email/Generator.py (line 180)
resolves the problem:

        else:
            \# Header's got lots of smarts, so use it.
            if h.lower() == 'subject':
                cont_ws = ' ' 
            else:
                cont_ws = '\\t'
            print \>\> self.\_fp, Header(
                v, maxlinelen=self.\_\_maxheaderlen,
                header_name=h,

continuation_ws=cont_ws).encode()

For more information you can e-mail me: matthias -at-
rubberbiscuit.nl

[warsaw]

Logged In: YES
user_id=12800

RFC 2822 specifies when and how long headers are supposed to
be wrapped, and the default Generator behavior is to be
compliant with this standard. I consider it a bug in your
mail reader that such long headers are displayed incorrectly
(other mail readers display long wrapped headers correctly).

Having said this, you have options. You can disable
wrapping altogether by passing maxheaderlen=0 to the
Generator constructor, or you can create a Generator
subclass which overrides the _write_headers() method and
passes a different value for continuation_ws.

[bbaetz]

Logged In: YES
user_id=495627

I disagree that this follows RFC2822. The RFC says:

The process of moving from this folded multiple-line
representation
of a header field to its single line representation is called
"unfolding". Unfolding is accomplished by simply removing
any CRLF
that is immediately followed by WSP. Each header field
should be
treated in its unfolded form for further syntactic and
semantic
evaluation.

This means that if python takes a header:

Subject: This is a long string

and wraps it to:

Subject: This is a\r\n\tlong string

then when the MUA "simply remov[es] any CRLF" the
whitespace, and we end up with:

Subject: This is a\tlong string

with a tab rather than a space, which doesn't look too good.
Some MUAs condense any following WSP into a single space,
but thats technically breaking the RFC.

(This affects mailman -
http://mail.python.org/pipermail/mailman-developers/2005-December/018410.html)