That's basically what I said...

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

Quoting Juergen Specht <js@juergenspecht.com>:

It was me that rejected the bug.

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.

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

Content-Disposition header has absolutely *nothing* to do with HTML 
e-mails.  Content-Disposition is an RFC header (see RFC 2183 - 
http://www.faqs.org/rfcs/rfc2183.html) that's been around for a long 
time.  This header *should* appear in every mail message (not exactly 
true - it is an optional header but we add it for redundancy sakes).   
You probably need to turn HTML composition off when sending messages 
if your messages are being rejected for HTML content.

When I send an email using the text editor, it still adds the header



Content-Disposition: inline



to all emails whether or not there is any inline content.



At least one, and possibly two mailing lists that I subscribe to 
reject the postings based on that header violating their NO HTML rules.



They have fired back that this header should only accompany multi-part 
messages and I shouldn't be sending multi-part messages to the mailing 
list.



Lunarpages.com who has installed this otherwise WONDERFUL upgrade says 
they cannot disable this header line.



Thanks for all the great work for a wonderful program.



Cheers,



Richard