[Email-SIG] problem with base64 encoded message/rfc822 attachment
matt at lickey.com
Sun Nov 21 21:51:25 CET 2004
Hans-Peter Jansen <hpj at urpla.net> writes:
> 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.
> Email-SIG mailing list
> Email-SIG at python.org
> Your options: http://mail.python.org/mailman/options/email-sig/matt%40lickey.com
More information about the Email-SIG