On Tuesday 26. September 2000 Rune Kristian Viken wrote:
>
> The Content-type header is invalid.  I use  Charset=3DISO-8859-1  but the
> content-type does not reflect this.  I can't define my own content-type
> mimeheader neither as kmail inserts a linefeed ..

This is a known problem and hopefully fixed in the final version.

> It should look like:
>
> Content-Type: text/plain; Charset=3DISO-8859-1
>
> It looks like:
>
> Content-Type: text/plain;
>  Charset=3DISO-8859-1

The line feed is completely correct. That is allowed in headers.

Regards
Michael H=E4ckel

On Tue 26 Sep 2000 Rune Kristian Viken wrote:
> Package: kmail
> Version: 1.1.94 (KDE 1.93 Beta >= 20000813)
> Severity: critical
>
> The Content-type header is invalid.  I use  Charset=ISO-8859-1  but the
> content-type does not reflect this.  I can't define my own content-type
> mimeheader neither as kmail inserts a linefeed ..
>
> It should look like:
>
> Content-Type: text/plain; Charset=ISO-8859-1
>
> It looks like:
>
> Content-Type: text/plain;
>  Charset=ISO-8859-1
>
> This is kinda critical since lots of the readers of my email doesn't get
> the right charset.  Which kinda.. sucks.

Sorry but you are wrong here.

The header is valid according to RFC822 (the email format definition). 
Have a look there to see yourself if you do not believe me ;-)

Details are like this:

If the following line starts with a whitespace the line is considered to
belong to the previous header line.

(Header) lines should not be longer than 72 characters and therefore
line breaks are valid and possible.

KMail uses these linebreaks to be sure that lines do not get longer.
If any email client has problems with this behaviour this email client
should be fixed not KMail :-)

Kind regards
Stefan

On Tue 26 Sep 2000 Rune Kristian Viken wrote:
> Package: kmail
> Version: 1.1.94 (KDE 1.93 Beta >= 20000813)
> Severity: critical
>
> The Content-type header is invalid.  I use  Charset=ISO-8859-1  but the
> content-type does not reflect this.  I can't define my own content-type
> mimeheader neither as kmail inserts a linefeed ..
>
> It should look like:
>
> Content-Type: text/plain; Charset=ISO-8859-1
>
> It looks like:
>
> Content-Type: text/plain;
>  Charset=ISO-8859-1

That is a valid way of specifying the charset. It's also very common. Still 
this is not the only problem KMail has supporting non-ISO-8859-1 charsets 
non-ISO-8859-1 is being worked on.

> This is kinda critical since lots of the readers of my email doesn't get
> the right charset.  Which kinda.. sucks.

It's a very important feature very important. But it is priority wishlist or 
normal because it doesn't affect KMail users (since they use ISO-8859-1 
languages only).

It's also a duplicate report so I'm closing it.

BFN
Don.

Bug still present in KMail 1.9.7 the worst thing is that it modifies incoming mail! For example, the same message received both by KMail and Thunderbird 2.0:

KMail:
Content-Type: text/plain;
  charset="us-ascii"

This break is after column 25 so
"(Header) lines should not be longer than 72 characters and therefore 
 line breaks are valid and possible." is false because whole line is 44 colums wide.
KMail adds: 0xa 0x20 bytes after ";" byte causing line break. Modifying -received- mail in KMail to add line break after column 25 to protect 44 column wide line against 72 column limit is the most stupid thing I ever saw in computers.

Thunderbird 2.0:
Content-Type: text/plain; charset="us-ascii"

The inbox folder should be read-only to protect mail against KMail trying to alter original messages. Someone should write a daemon to add +w during pop3 sessions and taking it away immediately after.