On 2013-09-26, Chris Angelico <[email protected]> wrote:
> On Thu, Sep 26, 2013 at 2:23 PM, Nils Bunger <[email protected]> wrote:
>> Yes, it's email.mime.MIMEApplication. I've pasted a snippet
>> with the imports below.
>>
>> I'm trying to use this to build a multi-part MIME message,
>> with this as one part.
>>
>> I really can't figure out any way to attach a binary part like
>> this to a multi-part MIME message without the encoding
>> issue... any help would be greatly appreciate!
>
> I partly responded just to ping your thread, as I'm not
> particularly familiar with the email.mime module. But a glance
> at the docs suggests that MIMEApplication is a "subclass of
> MIMENonMultipart", so might it be a problem to use that for
> multipart??
>
> It's designed to handle text, so you may want to use an encoder
> (like the default base64 one) rather than trying to push binary
> data through it.
>
> Random ideas, hopefully someone who actually knows the module
> can respond.
I got interested in it since I have never used any of the
modules. So I played with it enough to discover that the part of
the code above that converts the \r to \n is the flatten call.
I got to here and RFC 2049 and gave up.
The following guidelines may be useful to anyone devising a data
format (media type) that is supposed to survive the widest range of
networking technologies and known broken MTAs unscathed. Note that
anything encoded in the base64 encoding will satisfy these rules, but
that some well-known mechanisms, notably the UNIX uuencode facility,
will not. Note also that anything encoded in the Quoted-Printable
encoding will survive most gateways intact, but possibly not some
gateways to systems that use the EBCDIC character set.
(1) Under some circumstances the encoding used for data may
change as part of normal gateway or user agent
operation. In particular, conversion from base64 to
quoted-printable and vice versa may be necessary. This
may result in the confusion of CRLF sequences with line
breaks in text bodies. As such, the persistence of
CRLF as something other than a line break must not be
relied on.
(2) Many systems may elect to represent and store text data
using local newline conventions. Local newline
conventions may not match the RFC822 CRLF convention --
systems are known that use plain CR, plain LF, CRLF, or
counted records. The result is that isolated CR and LF
characters are not well tolerated in general; they may
be lost or converted to delimiters on some systems, and
hence must not be relied on.
So putting a raw CR in a binary chunk maybe be intolerable, and
you need to use a different encoder. But I'm out of my element.
--
Neil Cerutti
--
https://mail.python.org/mailman/listinfo/python-list
