Skip Menu |
 

This queue is for tickets about the MIME-Lite CPAN distribution.

Report information
The Basics
Id: 4154
Status: open
Priority: 0/
Queue: MIME-Lite

People
Owner: Nobody in particular
Requestors: julian [...] mehnle.net
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in:
  • 2.117
  • 3.0
  • 3.01
  • 3.01_01
  • 3.01_02
Fixed in: (no value)



Subject: MIME "binary" encoding is default but illegal
Download (untitled) / with headers
text/plain 1.7k
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... ;-)
Le Sam. Oct. 18 08:29:58 2003, guest a écrit : Show quoted text
> 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... ;-)
Hello, we have some bug too with our applications due to this non compliant RFC implementation. Could you check this please? Regards


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.