| Subject: | MIME "binary" encoding is default but illegal |
MIME::Lite's documentation states:
Encoding
Optional. The content transfer encoding that should be used to encode
your data. [...]
The default is taken from the Type; generally it is "binary" (no
encoding) for text/*, message/*, and multipart/*, and "base64" for
everything else. A value of "binary" is generally not suitable for
sending anything but ASCII text files with lines under 1000 characters,
so consider using one of the other values instead.
This is not entirely correct. In fact, a "binary" encoding is invalid even if only ASCII text with lines under 1000 characters are sent. RFC 2045 states:
6.2. Content-Transfer-Encodings Semantics
Mail transport for unencoded 8bit data is defined in RFC 1652. As of
the initial publication of this document, there are no standardized
Internet mail transports for which it is legitimate to include
unencoded binary data in mail bodies. Thus there are no
circumstances in which the "binary" Content-Transfer-Encoding is
actually valid in Internet mail. [...]
SMTP cannot transfer "binary" encoded messages. Even if the message body is in fact "7bit" encoded, an MTA cannot know this in advance and most MTAs will in fact croak when they see "Content-Transfer-Encoding: binary".
The default encoding behavior of MIME::Lite for text type or multipart message parts should be changed to something more intelligent, like choosing "8bit" and chopping long lines, or automatically encoding as "quoted-printable", and the documentation should state clearly that a "binary" encoding is not only "generally not suitable", but outright illegal when sending through SMTP.
I get far too many broken mails every day that my Courier MTA croaks about, so I hope broken MIME support can be fixed everywhere some time... ;-)