If the following eMail message is forwarded using kMail's "redirect" feature, the "To" header is garbled and the mail is rejected by my eMail server. (The reject might depend on my MTAs config, but the header is invalid/garbled in any case.) Received mail in plain text: Return-path: <mails.kmail-bug-test@gunter.example.com> Envelope-to: mails.kmail-bug-test@gunter.example.com Delivery-date: Wed, 09 Mar 2016 18:28:28 +0100 Received: from fw1-ks.relaix.net ([93.159.250.22] helo=zweiblum.localnet) by luggage.example.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <mails.kmail-bug-test@gunter.example.com>) id 1adhuN-0008F3-Vd for mails.kmail-bug-test@gunter.example.com; Wed, 09 Mar 2016 18:28:28 +0100 From: Gunter Ohrner <mails.kmail-bug-test@gunter.example.com> To: "'mails.kmail-bug-test@gunter.example.com'" <mails.kmail-bug-test@gunter.example.com> Date: Wed, 09 Mar 2016 18:28:27 +0100 Message-ID: <7116823.kZxEJ455uF@zweiblum.example.com> Organization: Ohrner IT GmbH User-Agent: KMail/5.0.3 (Linux/4.2.0-30-generic; KDE/5.18.0; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Subject: Test Test -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The future isn't what it used to be. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + PGP-verschlüsselte Mails bevorzugt! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The mail now stuck in my outbox looks as follows: Return-Path: <mails.kmail-bug-test@gunter.example.com> Envelope-to: mails.kmail-bug-test@gunter.example.com Delivery-date: Wed, 09 Mar 2016 18:28:28 +0100 Received: from fw1-ks.relaix.net ([93.159.250.22] helo=zweiblum.localnet) by luggage.example.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <mails.kmail-bug-test@gunter.example.com>) id 1adhuN-0008F3-Vd for mails.kmail-bug-test@gunter.example.com; Wed, 09 Mar 2016 18:28:28 +0100 From: Gunter Ohrner <mails.kmail-bug-test@gunter.example.com> Date: Wed, 09 Mar 2016 18:28:27 +0100 Message-ID: <7116823.kZxEJ455uF@zweiblum.example.com> Organization: Ohrner IT GmbH User-Agent: KMail/5.0.3 (Linux/4.2.0-30-generic; KDE/5.18.0; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Subject: Test Resent-Message-ID: <201603091829.15351@zweiblum.example.com> Resent-Date: Wed, 09 Mar 2016 18:29:15 +0100 Resent-From: Gunter Ohrner <mails.kmail-bug-test@gunter.example.com> To: 'mails.kmail-bug-test@gunter.example.com', mails.kmail-bug-test@gunter.example.com Resent-To: mails.kmail-bug-test-fwd_addr@gunter.example.com Test -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The future isn't what it used to be. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + PGP-verschlüsselte Mails bevorzugt! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See how the address consisting of an awkwardly formatted real name and the acutal address in the original "To" field is now split into two addresses, the first of which is invalid as it's quoted. My mail server does a header syntax check, complains and rejects the mail. Reproducible: Always
Still fails as of kMail 5.3.1.
why your email have a <double quote>+<simple quote> ?
I'll start with a disclaimer: The point is, I'm not even using these addresses, the bug described happens if I just want to bounce a mail which *contains* such an address - I'm using a totally plain new address as the bounce target. The mail that is being forwarded gets garbled in the process. How does it happen that such mail addresses get introduced into mails I receive? Good question. However, I see addresses formatted like this quite frequently. I guess it's an unlucky combination of different MUAs which first cause an address like localpart@example.com <localpart@example.com> to be generated from the pure address, and in later steps the "real name" part gets quoted somehow. Possibly also Akonadi address search - or possibly older versions thereof - might come into play, as addresses like this are often suggested to my by kMails address search. Then again, it might also be that Akonadi just extracted these strangely formatted addresses as-is from existing mails. In any case, I think the format - strange, as it is - is technically correct and addresses like this ought to work, shouldn't they?
localpart@example.com <localpart@example.com> is a valid address but 'localpart@example.com <localpart@example.com>' is not valid and smtp told you it. It doesn't accept to send it. => it's not a valid address.
(In reply to Laurent Montel from comment #4) > but 'localpart@example.com <localpart@example.com>' is not valid and smtp > told you it. It doesn't accept to send it. > => it's not a valid address. Right, but an address like that does not appear in these mails. The "To" address contained in the mail I received was "'mails.kmail-bug-test@gunter.example.com'" <mails.kmail-bug-test@gunter.example.com> This, I think, is a valid address with an admittedly strange looking quoted "display name" and an address specification in angle brackets. Thus kMail should not garble this address if I merely forward a mail which contains an address formatted this way. However, if I "bounce" a mail containing a "To" address like this, kMail destroys the "To" address line. (See the pasted "bounced" mail from above.) This should not happen, kMail should bounce the mail as-is.
I fear we're somehow not talking about the same issue. To summarize: * I receive an eMail, * I bounce it using kMail and * the generated bounce message contains a garbled / invalid "To" header. All I'm saying is that kMail should not garble the "To" header if I bounce a mail - even if it's formatted in an unusual, but apparently technically correct, way.
(In reply to Laurent Montel from comment #2) > why your email have a <double quote>+<simple quote> ? That shouldn't matter, that address is valid according to the RFC: <https://tools.ietf.org/html/rfc5322#section-3.4>.