This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Message.as_string should use "mangle_from_=unixfrom"?
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.2
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: r.david.murray Nosy List: ajaksu2, barry, kxroberto, r.david.murray
Priority: normal Keywords: patch

Created on 2006-03-28 09:17 by kxroberto, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
Message.py.patch kxroberto, 2006-03-28 09:17
Messages (6)
msg49877 - (view) Author: kxroberto (kxroberto) Date: 2006-03-28 09:17
--> attachment

It produced a message alteration by surprise for me
(and maybe does regularly).

Not sure but: Aren't UNIX mbox formates produced
usually together with unixfrom=True?

Also, when one wants to create UNIX mbox formats, one
should take extra care using individual Generator's.
The average .as_string() user maybe wants his message
unaltered.

Robert
msg83908 - (view) Author: Daniel Diniz (ajaksu2) * (Python triager) Date: 2009-03-21 02:03
I can't understand the problem :/
msg83929 - (view) Author: kxroberto (kxroberto) Date: 2009-03-21 10:05
"g = Generator(fp,mangle_from_=unixfrom)"
in that code location below? 
It produced exceptions often when message lines (or headerlines e.g.
Subject also when I remember right) begin with the char ">" or so.

--- Message.py.orig	2004-12-22 16:01:38.000000000 +0100
+++ Message.py	2006-03-28 10:59:42.000000000 +0200
@@ -126,7 +126,7 @@
         """
         from email.Generator import Generator
         fp = StringIO()
-        g = Generator(fp)
+        g = Generator(fp,mangle_from_=unixfrom)
         g.flatten(self, unixfrom=unixfrom)
         return fp.getvalue()
msg97608 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-01-11 22:01
If I understand correctly, this is related to issue 1440472.  There the complaint is made that what you get out is not what you put in, since unixfrom defaults to True.  But that's only true for __str__.  As kxroberto points out, in as_string it defaults to False.  Instead, he suggests, it could default to the value of unixfrom set on the Message object, which would make it at least a little bit more likely to preserve format of the message that was fed into it.
msg123841 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-12-12 17:39
On balance I think this would be a backward incompatible change that has insufficient benefit to be worth doing.  People who have working code will be depending on the existing defaults of the two methods, and changing this out from under them would be unkind.
msg148306 - (view) Author: kxroberto (kxroberto) Date: 2011-11-25 07:41
I'd still say this is a plain bug, which simply should be fixed.

"People who have working code" must have already a smart work around: either - or! : By doing the 5 low level code lines of .as_string() on their own. (there is no other way to produce clearly either a unixfrom=True or unixfrom=False Message). 
As of now this is simply neither nor. People are just quiet (I wonder), because the bug effect is rare. 

If somebody really wants to produce a unix mbox format for antiquated purposes, he would use unixfrom=True, when calling this function. (because otherwise its not complete unixfrom). And then the patched version is ok as well.

But when you call with unixfrom=False (default), a partially unixfrom=True mangled MIME body comes out. This is just buggy ...

Most striking is, that all lines in the message body (which the mail recipient reads), which start with the word "From", are converted to ">From". This is not acceptable. 

"a little bit more likely to preserve format of the message that was fed into it" :  Certainly mail message bodies must not be altered in a funny way when mangling is not ordered. 

I cannot imagine that sb can consciously or unconsciously rely on the bug. But in 99% of cases the patch would just fix peoples buggy programs.

If this really cannot be fixed, then at least a extra function next to as_string should be added (e.g. as_unmangled_string()), which allows creation of legal unmangled message. 
The current function can so far only produce a managled message, but consistently only then if in addition it is called explicitely with unixfrom=True ;-)
History
Date User Action Args
2022-04-11 14:56:16adminsetgithub: 43104
2011-11-25 07:41:06kxrobertosetmessages: + msg148306
2010-12-12 17:39:11r.david.murraysetstatus: open -> closed
resolution: wont fix
messages: + msg123841

stage: test needed -> resolved
2010-05-05 13:37:37barrysetassignee: barry -> r.david.murray
2010-01-11 22:01:12r.david.murraysetversions: + Python 3.2
nosy: + r.david.murray

messages: + msg97608

type: behavior
stage: test needed
2009-03-21 10:05:57kxrobertosetmessages: + msg83929
title: convenient Message.as_string to use mangle_from_=unixfrom ? -> Message.as_string should use "mangle_from_=unixfrom"?
2009-03-21 02:03:00ajaksu2setnosy: + ajaksu2
messages: + msg83908
2006-03-28 09:17:49kxrobertocreate