#!/usr/bin/env python
#Feedback to crunch@shopip.com
#Python 2.3.2 under OpenBSD 3.4 i386
import email

print r"""
Example of Python email generator bug.
If a MIME message is missing the terminating line, the
generator creates one for it -only it forgets to add the
\n\n to it. This causes the following message to be
concatenated to the first.
"""

#s1 is MIME missing terminating line;
#s2 is a proper MIME message.
s1="""Received: by spameater (127.0.0.1)...
From: "Victor Virus" <security@microsoft.com>
To: <poorsap@host.net>
Subject: Unterminated MIME to corrupt your mbox!
MIME-Version: 1.0
Content-Type: multipart/mixed;boundary="xxxx"

--xxxx
Content-Type: text/plain;

This is an unterminated MIME, like many viruses
generate. I don't care about rights of viruses,
but I do care if improper handling of MIME causes
following messages to be lost.

--xxxx


"""
s2=s1+"""--xxxx--\n\n""" #Create properly terminator
msg1=email.message_from_string(s1)
msg2=email.message_from_string(s2)
print str(msg1)+str(msg2)
print "p.s. Notice how the first message runs into the"
print "      second message."
print "      By adding the missing '--', this won't happen."

Logged In: YES 
user_id=12800

This really isn't a bug in the email package, since it's
doing what is expected of it.  The MIME RFC actually
attaches newlines to the front of any boundary and does not
specify any required newlines after the terminator.  If you
look carefully at msg1 and msg2, you'll find that for the
latter, all those extra newlines get assigned to the
.epilogue which, like the .preamble is text outside the MIME
encapsulation.

If you want to use  the output of the Generator to create a
Unix style mbox format file, you'll need to either add the
extra newlines to the epilogue yourself, or checked the
str() of msg1 to see if it contains the number of newlines
your external (read: mbox) format requires.