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

* Your Email Address
* Spam protection	Enter the letters below: . ..__ \ /._..__. \ /[__) >< \| \| \| \/ \| / \_\|_\|__\|
Comment	> Quoting Juergen Specht <js@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.
Attachment
Watch this ticket

Saved Queries