[Tickets #1449] RESOLVED: Content-Disposition: inline in all emails

[bugs at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=1449
-----------------------------------------------------------------------
 Ticket             | 1449
 Updated By         | Michael Slusarz <slusarz at mail.curecanti.org>
 Summary            | Content-Disposition: inline in all emails
 Queue              | Horde Base
 Version            | 3.0.2
 State              | Bogus
 Priority           | 1. Low
 Type               | Bug
 Owners             | 
-----------------------------------------------------------------------


Michael Slusarz <slusarz at mail.curecanti.org> (2005-02-27 22:17) wrote:

Quoting Juergen Specht <js at juergenspecht.com>:

> Hi Michael,
>
> I read your comment in ticket http://bugs.horde.org/ticket/?id=1449
> and have something to add. The CC'ed user Richard is a member of
> one of my mailing lists and since Horde got updated, all his emails
> get rejected, so he complained.
>
> Unfortunately you (?) rejected it as bogus, which does not really
> match the case. Let me explain (and I was actively involved in
> developing the Lyris listserver from 1997-1999, anti-spam product
> Mailshield, Nooper email delivery system etc, etc, so I speak SMTP).

It was me that rejected the bug.

> I run a mailing list for Nikon D-SLR users and require that every
> user sends "Plain Text" emails only to this mailing list. I filter
> for several header and send only 2 different auto-repliers back,
> one "no attachments allowed" and one "no HTML allowed". I could
> be more specific, but the members are photographers and not SMTP
> gurus.
>
> Richard sent messages to my list which contain the header:
>
> Content-Distribution: inline.
>
> You are (partly) right that this header is not an indicator for
> HTML mails (that's the misunderstanding because of my rejection
> message), but it's a MIME header. And without MIME you can not
> send HTML (that's the "partly" part).

Well, obviously this statement is not true (i.e. you can send anything you
want in the body of the message).  It is simply the MIME headers that
identify to the MUA what kind of data the body contains.

> MIME is defined (to quote RFC 2183):
>
> MIME specifies a standard format for encapsulating multiple pieces of
> data into a single Internet message.
>
> So the Horde user Richard tries to send a Plain Text message, but
> it ends up as a MIME message including the header in question.
>
> "Plain Text" is defined as:
>
> http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc2046.html#sec-4.1.3
> The simplest and most important subtype of "text" is "plain". This
> indicates plain text that does not contain any formatting commands or
> directives. Plain text is intended to be displayed "as-is", that is,
> no interpretation of embedded formatting commands, font attribute
> specifications, processing instructions, interpretation directives, or
> content markup should be necessary for proper display. The default
> media type of "text/plain; charset=us-ascii" for Internet mail
> describes existing Internet practice. That is, it is the type of body
> defined by RFC 822.

Hmmmm.... you are defining "Plain Text" using RFC 2046 - which is one of the
RFCs (2045-2049) that *defines MIME*.  All this definition is saying is that
if you ignore the MIME headers entirely, then the message should be treated
as plain text.

> However, MIME messages have a sub-type Content-Type: text/plain
> but this still does not make a MIME message a Plain Text message.

Actually, yes it does.  Read RFC 2046 [4.1.3] as quoted above:

  The default media type of "text/plain; charset=us-ascii" for Internet
mail
  describes existing Internet practice. That is, it is the type of body
  defined by RFC 822.

Therefore, a MIME message that either a) doesn't have the Content-Type
parameter, or b) has a Content-Type parameter of 'text/plain' is treated as
a RFC 822 text message.  An RFC 822 body *is* as basic Plain Text as you can
get.  Thus, sending a non-MIME message or sending a MIME message with either
a) or b) above provides the same body information.  The important part is
that the text in the body is completely plain text.  A "Plain Text" message
*does not* mean that there is no additional MIME headers.  A "Plain Text"
message simply means that there is no need for any formatting of the
contents to display correctly.

> So it's your call if you define it as a bug or just a misleading of
> your users, by making them think they send a "Plain Text" message
> when they really send a MIME message.
>
> Here is a good read why MIME is a bad idea for mailing lists:
>
> http://www.expita.com/nomime.html

I understand the points made on this page, but these concerns are something
an administrator should be dealing with, not an end user.  If you don't want
MIME formatting on your mailing list, that is fine, but you should allow
MIME-based text messages - just have a front end filter that filters out all
the MIME stuff you don't want.  I could write a 10-line program (or less) in
PHP using Horde that would input a text/plain message in MIME (or a
multipart/mixed message) and return a single text part without MIME
headers.

Additionally, I don't see how this problem is solved on the IMP side.  As
far as I can see there are two IMP solutions:
1) Send all text/plain messages from IMP without MIME information
This is obviously not the answer.  Not only do you lose *all* ability to
send either special characters or foreign characters without MIME, but you
also eliminate 'flowed' formatting, for example, which is the single best
thing to _ever_ happen to e-mail lists and something that appears to be
completely ignored by the webpage you have provided above.
2) Give the user an option to send "non MIME text messages"
Not only does this add unneeded complexity, but the amount of confusion on
the part of end users would more than outweigh the benefit.

These reasons, and others, are the reason this bug is marked bogus.