listserv.fnal.gov replies to my messages sent with kmail-4.8.1: --- Your message contains a QUOTED-PRINTABLE encoded composite MIME part, which is not allowed by Internet standards (see RFC2045, section 6.4, paragraph 5). In plain English, an error in your mail program, or in a firewall or mail gateway between your computer and LISTSERV, has caused an error in the format of your message. --- It refers to this paragraph: --- Certain Content-Transfer-Encoding values may only be used on certain media types. In particular, it is EXPRESSLY FORBIDDEN to use any encodings other than "7bit", "8bit", or "binary" with any composite media type, i.e. one that recursively includes other Content-Type fields. Currently the only composite media types are "multipart" and "message". All encodings that are desired for bodies of type multipart or message must be done at the innermost level, by encoding the actual body that needs to be encoded. --- The quoted message listserv attached shows that kmail did indeed violate this: --- Content-Type: multipart/signed; boundary="..."; micalg="pgp-sha1"; protocol="application/pgp-signature" Content-Transfer-Encoding: quoted-printable --- This is the same as Akonadi saved in my sent folder, so I can exclude a bug in a mail gateway. The issue did not happen with kmail-4.8.0 or 4.7.4.
I confirm this bug. Kmail2 has problem with quoted printable charakter encodings in incoming mails. Mostly from Gmail, but not usually. Problem with czech (central european) charakters. I attached part of message. ........... --047d7b33d6e051cffd04c0b3560b Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Ahoj, m=E9 jm=E9no je Johana Schov=E1nkov=E1 a p=ED=B9u Ti za skautsk=FD odbor Sk= auting pro v=B9echny. Mailov=FD kontakt na Tebe jsme z=EDskali z datab=E1ze SkautISu, = .............
I can confirm the bug for 4.9 This bug may cause trouble for other mail client. It seems that Outlook and Lotus Notes have cant interpret / display kmail generated messages with a "Content-Transfer-Encoding: quoted-printable" in the message header. To change this should not be a to big task. Thomas
Setting status to confirmed.
(In reply to comment #2) > I can confirm the bug for 4.9 > > This bug may cause trouble for other mail client. It seems that Outlook and > Lotus Notes have cant interpret / display kmail generated messages with a > "Content-Transfer-Encoding: quoted-printable" in the message header. I can add that this bug holds recent Thunderbird versions with Enigmail (TB 17, enigmail 1.4.6) off from decrypting OpenPGP/MIME encrypted emails sent by kmail2.
(In reply to comment #4) > I can add that this bug holds recent Thunderbird versions with Enigmail (TB > 17, enigmail 1.4.6) off from decrypting OpenPGP/MIME encrypted emails sent > by kmail2. More specifically, here is the bug report at Enigmail: https://sourceforge.net/p/enigmail/bugs/77/
(In reply to comment #1) > I confirm this bug. Kmail2 has problem with quoted printable charakter > encodings in incoming mails. Mostly from Gmail, but not usually. Problem > with czech (central european) charakters. I attached part of message. > ........... > --047d7b33d6e051cffd04c0b3560b > Content-Type: text/plain; charset="ISO-8859-2" > Content-Transfer-Encoding: quoted-printable > > Ahoj, > > m=E9 jm=E9no je Johana Schov=E1nkov=E1 a p=ED=B9u Ti za skautsk=FD odbor Sk= > auting pro > v=B9echny. Mailov=FD kontakt na Tebe jsme z=EDskali z datab=E1ze SkautISu, = > ............. Hello Tarpast, could it be that the behaviour you describe is a different bug? It seems to refer to displaying and not the sending of messages.
Hello Daniel, yes, you have right. It was my quickly reaction. Now, I am using Kmail 4.9.5 and this bug appear rarely - come 2 identical messages, first OK, second with broken encoding. regards Michael (Tarpast) ---------- Původní zpráva ---------- Od: Daniel Hornung <daniel.hornung@gmx.de> Datum: 27. 3. 2013 Předmět: [kmail2] [Bug 296629] kmail2 uses quoted-printable encoded composite mime parts, violating RFC2045 "https://bugs.kde.org/show_bug.cgi?id=296629 --- Comment #6 from Daniel Hornung <daniel.hornung@gmx.de> --- (In reply to comment #1) > I confirm this bug. Kmail2 has problem with quoted printable charakter > encodings in incoming mails. Mostly from Gmail, but not usually. Problem > with czech (central european) charakters. I attached part of message. > ........... > --047d7b33d6e051cffd04c0b3560b > Content-Type: text/plain; charset="ISO-8859-2" > Content-Transfer-Encoding: quoted-printable > > Ahoj, > > m=E9 jm=E9no je Johana Schov=E1nkov=E1 a p=ED=B9u Ti za skautsk=FD odbor Sk= > auting pro > v=B9echny. Mailov=FD kontakt na Tebe jsme z=EDskali z datab=E1ze SkautISu, = > ............. Hello Tarpast, could it be that the behaviour you describe is a different bug? It seems to refer to displaying and not the sending of messages.
(In reply to comment #7) So your problem is the one described in bug #292767? Then this bug probably can be closed as soon as the sending problem is fixed.
*** This bug has been marked as a duplicate of bug 289722 ***
I am using KMail 4.14.2 on Ubuntu 14.04 and am still experience this issue. Please reopen. Listserv replies: """ Your message contains a QUOTED-PRINTABLE encoded composite MIME part, which is not allowed by Internet standards (see RFC2045, section 6.4, paragraph 5). In plain English, an error in your mail program, or in a firewall or mail gateway between your computer and LISTSERV, has caused an error in the format of your message. """ Excerpt from the message returned by listserv: """ […] User-Agent: KMail/4.14.2 (Linux/3.13.0-44-generic; KDE/4.14.2; x86_64; ; ) […] MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1643101.pK0q01Qtpq"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart1643101.pK0q01Qtpq Content-Type: multipart/mixed; boundary="nextPart1991752.9pWY7iA1iV" Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. […] """ This message also has two 500KiB PDF attachments: """ =2D-nextPart2164026.fLyKns4tNR Content-Disposition: attachment; filename="[…].pdf" Content-Transfer-Encoding: base64 Content-Type: application/pdf; name="[…].pdf" """
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it. Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
KMail 5.5.1 does not specify any Content-Transfer-Encoding at all anymore: ``` MIME-Version: 1.0 Content-Type: multipart/signed; boundary="..."; micalg="pgp-sha256"; protocol="application/pgp-signature" ``` I.e. it defaults to 7bit encoding: `"Content-Transfer-Encoding: 7BIT" is assumed if the Content-Transfer-Encoding header field is not present.` (RFC 2045, Section 6.1, https://tools.ietf.org/html/rfc2045#section-6.1) Thus this bug can be considered RESOLVED/FIXED.