message returned by poplib to email.Messge instance

Thu Nov 29 15:35:13 EST 2001

Aaron:

Sorry I was off the beam. I'm not using 2.2 or email yet.

Because I suspected you might be right about the dashes, I took a look
at a MIME-compliant email with an attachment, which I know to be
correctly displayed in Outlook Express and Netscape Navigator, and
therefore complies with standards ... Crap! it looks like those dashes
belong in there, though I never remember seeing them before! And there's
a final set following the last terminator. Perhaps I need to read the
RFCs again...

The real problem appears to be after the "To:" header. The Unix-style
"From" line appears after a blank line, which according to RFC 822 (and,
presumably, 2822) terminates the headers. Which means that there is no
Content-Type header, and therefore no boundary. Maybe this is a bug in
the library, I dunno. Or maybe it's just that the header invalidly
includes a blank line.

regards
 Steve
--
http://www.holdenweb.com/

----- Original Message -----
From: "Aaron Sterling" <dhaaron at hotpop.com>
Newsgroups: comp.lang.python
To: "Steve Holden" <sholden at holdenweb.com>
Sent: Thursday, November 29, 2001 3:12 PM
Subject: Re: message returned by poplib to email.Messge instance

> >It's possibly as simple as the ommission of carriage returns? Offhand
I
> >don't remember for sure, but I suspect that missing CR's can cause
problems.
> >Here's an example I use in "Python Web Programming" -  it uses a
StringIO to>
> >stringify the message, but apart form that it's probably not too
different
> >from your code (cStringIO would be faster...):
> [snip]
>
> Thanks for the reply, and I don't mean to be picky, but that's not
what I need :-). even with '\r\n'.join(lines), I am still
> getting the same problem. I am able to read the message fine. The
problem is that the factory function,
> message_from_string in the email package does not return an object
tree that is indicative of the messages multipart
> nature.  What I am working on is a program similiar to CVS, but
distributed so that you do not need a central
> repository or server on the internet. It works by sending updates
through a pipe over the internet. The nature of this
> pipe is irrelevent, but for starters I am using email.  I have defined
a module, mail, with two function:
>
>        make_mail_update(update_list):
>              """returns a mime message with two attachements. the
update objects are pickled in 0. The authorization
>                   is in 1"""
>
>          read_mail_update(update_list):
>            """authenticate the update and then return the unpickled
update object"""
>
>          although it refers to an update object, it can be any object
>
> >>>  import mail
> >>>  test = mail.update_make_mail([0, 1, 2, 3 ,4])
> >>> mail.read_mail_update(test)
> [0, 1, 2, 3, 4]
>
> I need the mime capabilities of the email package, and i need the
message to be recognized as multipart. I extract
> the relevent information in read_mail_update(message) using:
>
>      pickled_update = messgage.get_payload(0).get_payload().strip()
>
> This works fine as long as i dont send it over the network. When I do,
the get_payload method of the message
> object acts as if it is not a multipart message. Even doing it
straight from the interpreter, using no logic associated
> with my program, I get the same problem:
>
> Python 2.2b2 (#26, Nov 16 2001, 11:44:11) [MSC 32 bit (Intel)] on
win32
> Type "copyright", "credits" or "license" for more information.
> IDLE 0.8 -- press F1 for help
> >>> import poplib
> >>> import email
> >>> pop = poplib.POP3('pop.hotpop.com')
> >>> pop.user('dhaaron')
> '+OK'
> >>> pop.pass_('JHGF)(*&')
> '+OK'
> >>> pop.stat()
> (2, 2350)
> >>> message = pop.retr(1)
> >>> pop.quit()
> '+OK'
> >>> junk, lines, junk = message
> >>> i = 0
> >>> for line in lines:
> print i, line
> i += 1
>
>
> 0 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net
[207.69.200.246])
> 1 by mx2.hotpop.com (Postfix) with ESMTP id 2147E178035
> 2 for <dhaaron at hotpop.com>; Thu, 29 Nov 2001 18:51:28 +0000 (UTC)
> 3 Received: from user-2ivf29o.dialup.mindspring.com ([165.247.137.56])
> 4 by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1)
> 5 id 169WHQ-000264-00
> 6 for dhaaron at hotpop.com; Thu, 29 Nov 2001 13:51:28 -0500
> 7 Message-Id: <E169WHQ-000264-00 at smtp10.atl.mindspring.net>
> 8 From: dhaaron at hotpop.com
> 9 Date: Thu, 29 Nov 2001 13:51:28 -0500
> 10 To: undisclosed-recipients:;
> 11
> 12 From nobody Thu Nov 29 13:51:20 2001
> 13 Content-Type: multipart/mixed;
boundary="===============69927062638266468=="
> 14 MIME-Version: 1.0
> 15 Subject: DDES updates
> 16 From: <dhaaron at hotpop.com>
> 17 To: <dhaaron at hotpop.com>
> 18
> 19 --===============69927062638266468==
> 20 Content-Type: text/plain; charset="us-ascii"
> 21 MIME-Version: 1.0
> 22 Content-Transfer-Encoding: 7bit
> 23
> 24 (lp0
> 25 I1
> 26 aI2
> 27 aI3
> 28 aI4
> 29 a.
> 30
> 31 --===============69927062638266468==
> 32 Content-Type: text/plain; charset="us-ascii"
> 33 MIME-Version: 1.0
> 34 Content-Transfer-Encoding: 7bit
> 35
> 36 authentification not yet implemented
> 37
> 38 --===============69927062638266468==--
> >>> mime_message = email.message_from_string('\r\n'.join(lines))
> >>> mime_message.is_multipart()
> 0
> >>>
>
>
> as you can clearly see, It is a multi part message. The one thing I
can think of is the definition of the boundary in line
> 13. this does not match exactly lines 19, 31, 38. Is this complient
with the mime standard?
>
>
>
>