Quoting mailing lists <[email protected]>:
I did another test with RoundCube and it has not problem showing the
attachment (even with the Content-Transfer-Encoding field empty)
Roundcube is badly broken then. *Directly* from the MIME
specification (RFC 2045 [6.4]):
Any entity with an unrecognized Content-Transfer-Encoding must be
treated as if it has a Content-Type of "application/octet-stream",
regardless of what the Content-Type header field actually says.
Which makes perfect sense. What if the content wasn't 7bit text but
was, instead, base64 data? Potentially showing a user MEGABYTES of
base64 encoded data is a terrible idea. You can only assume a part is
in 7bit when the header doesn't exist AT ALL (RFC 2045 [6.1]).
A mail-user agent can't guess at the contents of the part. This is an
unexpected, and potentially dangerous action. This is no different
than if a message doesn't contain a MIME-Version part: even if the
data *looks* like MIME data, it *isn't* and you can't assume as much.
michael
___________________________________
Michael Slusarz [[email protected]]
--
IMP mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [email protected]
