[ python-Feature Requests-1349106 ] email.Generators does not separates headers with "\r\n"

[SourceForge.net]

Feature Requests item #1349106, was opened at 2005-11-05 16:50
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1349106&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
>Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Manlio Perillo (manlioperillo)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Generators does not separates headers with "\r\n"

Initial Comment:
Regards.

The email.Generator module does not separates headers
with "\r\n".


Manlio Perillo

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-01-08 22:10

Message:
Logged In: YES 
user_id=12800
Originator: NO

I am reopening this as a feature request.  I still think it's better for
protocols that require these line endings to ensure that their data is
standards compliant, but I can see that there may be other use cases where
you'd want to generate protocol required line endings.  I'm not totally
convinced, but it's worth opening the issue for now and discussing this on
the email-sig.

----------------------------------------------------------------------

Comment By: Thomas Viehmann (t-v)
Date: 2007-01-08 21:34

Message:
Logged In: YES 
user_id=680463
Originator: NO

Hi,

could you please reconsider closing this bug and consider fixing it or at
least providing an option for standard behaviour?
Leaving aside the question of performance impact of postprocessing in
longer mails (for those, email may not a be good optionin the first
place), the module as is renders the email.Generator mostly useless for
multipart messages with binary data that needs to be standards compliant,
e.g. Multipart-Messages containing images, possibly signed or uploading
(with httplib) multipart/form-data.

Thank you for your consideration.

Kind regards

Thomas

----------------------------------------------------------------------

Comment By: Manlio Perillo (manlioperillo)
Date: 2006-01-20 10:05

Message:
Logged In: YES 
user_id=1054957

But the generator does not output in native line endings!

On Windows:
>>> from email.Message import Message
>>> msg = Message()
>>> msg["From"] = "me"
>>> msg["To"] = "you"
>>> print repr(msg.as_string())
'From: me\nTo: you\n\n'


----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-01-17 23:47

Message:
Logged In: YES 
user_id=12800

I hear what you're saying, but so far, it has been more
convenient for developers when the generator outputs native
line endings.  I can see a case for a flag or other switch
on the Generator instance to force RFC 2822 line endings.

I would suggest joining the email-sig and posting a request
there so the issue can be discussed as an RFE.

----------------------------------------------------------------------

Comment By: Manlio Perillo (manlioperillo)
Date: 2006-01-17 16:26

Message:
Logged In: YES 
user_id=1054957

I do not agree here (but I'm not an expert).

First - the documentation says:
"""The email package attempts to be as RFC-compliant as
possible, supporting in addition to RFC 2822, such
MIME-related RFCs as RFC 2045, RFC 2046, RFC 2047, and RFC 2231.
"""

But, as I can see, the generated email does not conform to
RFC 2822.

Second - I use email package as a "filter".
read raw email text, do some processing, generate raw email
text.

Really, I don't understand why generated headers don't are
separed by '\r\n' and one must rely on an external tool for
the right conversion.

Thanks.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-01-17 12:54

Message:
Logged In: YES 
user_id=12800

The module that speaks the wire protocol should do the
conversion.  IMO, there's no other way to guarantee that
you're RFC compliant.  You could be getting your data from
the email package, but you could be getting it from anywhere
else, and /that/ source may not be RFC line ended either. 
Since you can't change every possible source of data for
NNTP or SMTP, your network interface must guarantee conformance.

----------------------------------------------------------------------

Comment By: Manlio Perillo (manlioperillo)
Date: 2006-01-17 09:20

Message:
Logged In: YES 
user_id=1054957

Ok, thanks.
But what if I don't use the smtplib module?

I discovered the bug because I have written a small NNTP
server with twisted, using email module for parsing...


----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-01-17 05:35

Message:
Logged In: YES 
user_id=12800

Correct; this is by design.  If you're worried about
protocols such as RFC 2821 requiring \r\n line endings,
don't. The smtplib module automatically ensures proper line
endings for the on-the-wire communication.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1349106&group_id=5470