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

bugs at bugs.horde.org bugs at bugs.horde.org
Wed Mar 2 22:21:43 PST 2005


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-03-02 22:21) wrote:

>> 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




More information about the bugs mailing list