Version: (using KDE KDE 3.2.3) Installed from: RedHat RPMs Compiler: gcc 3.3.3 standard fedora core 2 version OS: Linux I've got a slightly malformed message here with Content-Type multipart/mixed but without a header field MIME-VERSION: 1.0 Kmail displayes this mail as a MIME-Multipart Mail and shows the above header field in the source code window. RFC 2045 sais in '4. MIME-Version Header Field': > Messages composed in accordance with this document MUST include such > a header field, with the following verbatim text: > > MIME-Version: 1.0 Which IMHO means, if there's no such header field it ain't MIME. No matter what follows. I don't know if you consider this a bug but I thought I'd mention it. Best regards... Stephan
I'm not entirely sure whether the problem _I_ am experiencing is the same the original reporter described, but it sounds as if it was. I'm using KMail 1.7.2 on KDE 3.3.2, installed from Debian packages. When I create a new message and choose "Inline OpenPGP (deprecated)" as the crypto format, the message does get these MIME headers: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline But there is no "MIME-Version" header. This is incompliant with RFC 2045. If I choose a different crypto format, e.g. "OpenPGP/MIME", I get appropriate headers, including a "MIME-Version" header: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2677227.B7ZIK2ayu8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Please fix KMail to _always_ generate a "MIME-Version: 1.0" header, too, when generating other MIME headers.
I can confirm both issues in kmail trunk svn r860337. KMail opens fine messages that do not include the MIME-Version header and it also does not generate such a header in "Inline OpenPGP (deprecated)" encryption mode.
I do not see this as a bug when kmail shows a message which is not RFC2045 comliant. On the contrary, there was Internet mail just before RFC2045 so kmail must make sure to be able to read mails as good as possible. (see RFC822) Also, when kmail produces a mail which does not have the MIME-version header, then it's simply not RFC2045 compatible - which does not mean it's an invalid mail.
Would be magically solved by using file-magic I think. Marking as a duplicate because of that. *** This bug has been marked as a duplicate of bug 199537 ***