[Email-SIG] problem with base64 encoded message/rfc822 attachment

[Matt Armstrong]

Hans-Peter Jansen <hpj at urpla.net> writes:

> Hi,
>
> I'm trying to understand the behaviour of email.Message, processing a 
> base64 encoded message/rfc822 payload.

RFC 2046 section 5.2.1 has this to say about message/rfc822:

   No encoding other than "7bit", "8bit", or "binary" is permitted for
   the body of a "message/rfc822" entity.  The message header fields are
   always US-ASCII in any case, and data within the body can still be
   encoded, in which case the Content-Transfer-Encoding header field in
   the encapsulated message will reflect this.  Non-US-ASCII text in the
   headers of an encapsulated message can be specified using the
   mechanisms described in RFC 2047.

So, a base64 encoded

 Using the sligthly modified 
> version of email-unpack.py, the attached  mail results in 2 
> attachments written:
>
> write 2:text/plain [7bit] to tmp/part-001.ksh
> ignore 3:message/delivery-status []
> ignore 4:text/plain []
> ignore 5:text/plain []
> ignore 6:message/rfc822 [base64]
> write 7:text/plain [] to tmp/part-006.bin
>
> While part 2 is fine as expected, part 7 looks strange, since it seems 
> to belong to the base64 encoded part 6. Consequently, the written 
> file is undecoded, which is not what I want/need. The encoding itself 
> is consistent, BTW. Who is wrong here?
>
> Could somebody shed some light on this? I would really like to base a 
> attachment filter on this module, and its precursor based on rfc822/
> mimetools felt much more backwardly to me..
>
> I'm on python 2.3[.4] here.
>
> Cheers,
> Pete
>
>
>
> _______________________________________________
> Email-SIG mailing list
> Email-SIG at python.org
> Your options: http://mail.python.org/mailman/options/email-sig/matt%40lickey.com

-- 
matt