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

* Your Email Address
* Spam protection	Enter the letters below: __ . .__ .___.. , / `\| [__) _/ \./ \__.\|___\| \./__. \|
Comment	>>> 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. > > > > That's basically what I said... > > > >> 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. > > > > In an ideal world I would agree with you, however because of spammers > > and virus authors try to sneak through all existing filters, a "Plain > > Text" message should not contain any additional headers if they > > are not necessary. > > > >> 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. > > > > See above. Of course I can filter and let only the "Plain Text" > > part through, but this does not solve the problem of these thousands > > of possible combinations of headers and content. And I don't do myself > > a favor to write a filter if an email client could just get rid of > > the "Content-Distribution: inline" header if there is nothing else > > than Plain Text in the mail, MIME or not. > > > > By rejecting this header for a mailing list which actually allows only > > Plain Text mails (also MIME marked as Plain Text without > > "Content-Distribution: inline" header) I have a 100% save mailing > > list and there is no chance that any user ever gets any attachment, > > virus or in any way "Rich Text" email. Making just one exception > > in my policy opens a big can of worms. > > > >> 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. > > > > I agree that flowed formatting is a plus, but can be archived even in > > non-MIME emails. Here is a nice page of a F=F fan: > > > > http://www.joeclark.org/ffaq.html > > > > But anyway, this is not really the problem. > > > >> 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. > > > > No, it's not necessary to give end-users more confusing options, > > but if I would write an email client, I would always send the > > lowest common denominator after checking the content of the email. > > > > If it's all (even the subject) written in plain 7bit ascii text, why > > bother to send additional and in this case obsolete headers? > > > > The whole point of my email was that IMP is the only email client > > I came across in the last 4 years which add the "Content-Distribution: > > inline" header to all emails, necessary or not. > > > > It also seems that you just updated IMP and added this "feature", because > > Richard used it before and never got rejected. > > > >> These reasons, and others, are the reason this bug is marked bogus. > >> Feel free to comment/criticize - I just ask that you add to the bug > >> report so that all may be able to see the conversation. > > > > Please feel free to add this mail to your bug report (but please mask > > my email address somehow), but I will probably not add more to the > > discussion. If you want to send this header, so be it, you don't > > violate any RFCs, but IMP users will be forever rejected from my > > lists. Not that I am that important anyway ;) > > > > Thanks for your time, > > > > Juergen
Attachment
Watch this ticket

Saved Queries