[kmail2] [Bug 447297] New: UTF-8 characters decoded incorrectly on reply
https://bugs.kde.org/show_bug.cgi?id=447297
Bug ID: 447297
Summary: UTF-8 characters decoded incorrectly on reply
Product: kmail2
Version: unspecified
Platform: openSUSE RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: composer
Assignee: kdepim-b...@kde.org
Reporter: k...@snafu.de
Target Milestone: ---
SUMMARY
If Configure > Composer > Charset > Keep original charset ... is checked,
quoted UTF-8 encoded messages are incorrectly decoded as Latin-1 or similar on
reply, leading to character sequences such as ü for ü or é for é and so on.
If the checkbox is unchecked, non-ASCII UTF-8 characters are decoded correctly.
See ADDITIONAL INFORMATION below for some settings of mine that might be
related. Happy to provide additional information.
STEPS TO REPRODUCE
1. Choose an eMail with Content-Type: text/html; charset=UTF-8 (or"utf-8"),
Content-Transfer-Encoding: base64 (not sure transfer encoding matters)
2. Check "Keep original charset ..." (see above)
3. Reply to chosen eMail
4. Uncheck "Keep original charset ..." (see above)
5. Reply to chosen eMail
OBSERVED RESULT
UTF-8 characters decoded as e.g. ü instead of ü when "Keep original charset
..." is checked.
UTF-8 characters correctly decoded when "Keep original charset ..." is
unchecked.
EXPECTED RESULT
UTF-8 characters correctly decoded even when "Keep original charset ..." is
checked.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: openSUSE Tumbleweed 20211212
KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.88.0
Qt Version: 5.15.2
ADDITIONAL INFORMATION
Some other settings of mine:
Configure > Appearance > General > Override character encoding: Auto
Configure > Composer > General > Reply or forward ... (plain text or HTML):
unchecked
Configure > Composer > General > Reply or forward ... (plain text or HTML):
unchecked
Configure > Composer > Charset: {utf-8, iso-8859-1, us-ascii, utf-8 (locale)}
in this order
--
You are receiving this mail because:
You are watching all bug changes.
[kmail2] [Bug 392239] CR linebreaks in message view are not shown
https://bugs.kde.org/show_bug.cgi?id=392239 --- Comment #10 from kzi --- Salut Laurent, > But which mailer generates it ? While I think KMail should be capable do deal with any kind of line break, no matter the source, the answer (taken from the header) is: esmtps (Exim 4.92.3) I received the mail from the accounting of a web shop as an invoice carrier (hence the nondisclosure in the first place), so it's likely to originate from some kind of ERP system. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 392239] Messages or parts with Content-Transfer-Encoding: base64 have no line breaks displayed
https://bugs.kde.org/show_bug.cgi?id=392239 --- Comment #7 from kzi --- (In reply to kzi from comment #6) > Apparently 0D (CR) characters are stripped from the resulting message. ...or just not rendered as line break. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 392239] Messages or parts with Content-Transfer-Encoding: base64 have no line breaks displayed
https://bugs.kde.org/show_bug.cgi?id=392239 --- Comment #6 from kzi --- Thx for hinting mbox redaction. While trying to come up with a disclosable example I found the cause is the line break character used in the base64-decoded plain text message: Apparently 0D (CR) characters are stripped from the resulting message. Please find attached made-up mbox files with different line break encodings of the source plain text. You'll find that 0D.mbox doesn't break correctly while the other two do. I created the files after the mail example where I first encountered the issue. To me it is not unlikely that the issue may be completely independent of Content-Type and Content-Transfer-Encoding. However I do not have the time now to do more thorough and complete testing. Feel free to create a more suitable bug ticket if sensible. The issue continues to exist in KMail 5.14.0. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 392239] Messages or parts with Content-Transfer-Encoding: base64 have no line breaks displayed
https://bugs.kde.org/show_bug.cgi?id=392239 --- Comment #5 from kzi --- Created attachment 128669 --> https://bugs.kde.org/attachment.cgi?id=128669&action=edit mbox where plain text has 0D0A (CRLF) line breaks -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 392239] Messages or parts with Content-Transfer-Encoding: base64 have no line breaks displayed
https://bugs.kde.org/show_bug.cgi?id=392239 --- Comment #4 from kzi --- Created attachment 128668 --> https://bugs.kde.org/attachment.cgi?id=128668&action=edit mbox where plain text has 0D (CR) line breaks -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 392239] Messages or parts with Content-Transfer-Encoding: base64 have no line breaks displayed
https://bugs.kde.org/show_bug.cgi?id=392239 --- Comment #3 from kzi --- Created attachment 128667 --> https://bugs.kde.org/attachment.cgi?id=128667&action=edit mbox where plain text has 0A (LF) line breaks -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 392239] Messages or parts with Content-Transfer-Encoding: base64 have no line breaks displayed
https://bugs.kde.org/show_bug.cgi?id=392239 kzi changed: What|Removed |Added Summary|Messages or parts have no |Messages or parts with |line breaks displayed |Content-Transfer-Encoding: ||base64 have no line breaks ||displayed -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 392239] New: Messages or parts have no line breaks displayed
https://bugs.kde.org/show_bug.cgi?id=392239 Bug ID: 392239 Summary: Messages or parts have no line breaks displayed Product: kmail2 Version: 5.7.2 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: k...@snafu.de Target Milestone: --- Messages or parts of multipart messages with Content-Type: text/plain;charset="utf-8" Content-Transfer-Encoding: base64 are displayed without line breaks (but spaces are kept). I apologize to not include an example, but the mails in question contain information that I'd rather not have disclosed here. I verified by base64-decoding the blocks in question, and the results show line breaks and thus appear as "well-formatted plain text". Mails from the same source but with Content-Type: text/plain;charset="utf-8" Content-Transfer-Encoding: quoted-printable are shown alright ,so it's likely due to base64 post-processing. Encountered on Tumbleweed. -- You are receiving this mail because: You are watching all bug changes.
[kmailtransport] [Bug 388160] ksmtp EHLO sends server hostname as domain parameter by default
https://bugs.kde.org/show_bug.cgi?id=388160 --- Comment #3 from kzi --- Thank you, Fabian! localhost.invalid and foo.localnet make up nice domain names, too. :) -- You are receiving this mail because: You are watching all bug changes.
[kmailtransport] [Bug 388160] ksmtp EHLO sends server hostname as domain parameter by default
https://bugs.kde.org/show_bug.cgi?id=388160 --- Comment #1 from kzi --- My system is openSUSE Tumbleweed. kmailtransport 17.12.0-1.1-x86_64 ksmtp 17.12.0-3.1-x86_64 (How does that relate to the 'Version' dropdown above?) -- You are receiving this mail because: You are watching all bug changes.
[kmailtransport] [Bug 388160] New: ksmtp EHLO sends server hostname as domain parameter by default
https://bugs.kde.org/show_bug.cgi?id=388160 Bug ID: 388160 Summary: ksmtp EHLO sends server hostname as domain parameter by default Product: kmailtransport Version: unspecified Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: k...@snafu.de Target Milestone: --- As Fabian Vogt pointed out elsewhere (https://bugs.kde.org/show_bug.cgi?id=387926#c30), ksmtp sends the server hostname as the EHLO domain parameter (confirmed via telnet and wireshark): EHLO mail.snafu.de 550 EHLO/HELO not allowed by local policy. In this case my Provider rejects the EHLO, which results in failure to transport the e-mail. Any other domain will be accepted: EHLO foo.bar 250-sour.ops.eusc.inter.net Hello ... Consequently, this can be worked around by specifying an explicit custom hostname in the SMTP settings e.g. in kmail2. It has been recommended somewhere that in case the client has no (meaningful) domain, the bracketed IP address should be sent, such as: EHLO [nnn.nnn.nnn.nnn] In my case, this is accepted, too. I'm not 100% sure this is a bug, but it seems sane client behavior not to tell the server it ought to talk to itself. It's understandable that the server would test for this domain and none else. This issue didn't arise until a couple of days ago. I do not know what the default EHLO parameter was before that change. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 387926] Release version 17.12: Sending a mail with SMTP fails with: org.kde.pim.ksmtp: Socket error: 1
https://bugs.kde.org/show_bug.cgi?id=387926 --- Comment #31 from kzi --- (In reply to Fabian Vogt from comment #30) > ksmtp sends the server's hostname instead of the local hostname by accident > with the "EHLO" command. The mail.snafu.de server rejects that immediately, > but example.com works. > > Please try this workaround to confirm: In the account configuration dialog, > in the "advanced" tab, enter "example.com" as "Send custom hostname to > server". Indeed, that works around my issue. After your hint I learned: > telnet mail.snafu.de 587 EHLO foo.bar 250-... (ok) EHLO mail.snafu.de 550 EHLO/HELO not allowed by local policy. Connection closed by foreign host. So seemingly /every/ EHLO domain parameter but the server host is accepted! Thank you so much for this offtopic help! > Please open a new bug report for that. I will, now that I have a clue. ;) -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 387926] Release version 17.12: Sending a mail with SMTP fails with: org.kde.pim.ksmtp: Socket error: 1
https://bugs.kde.org/show_bug.cgi?id=387926 kzi changed: What|Removed |Added CC||k...@snafu.de --- Comment #28 from kzi --- I can confirm the issue on Tumbleweed, KMail 5.7.0, server mail.snafu.de port 25 or 587. Encryption 'None' or TLS results in Socket error: 2, while SSL gives Socket error: 9. TLS/25/PLAIN is autodetected. Provider says 'SSL' (but probably means TLS) and above ports. The ksmtp patch 17.12.0-3-1 rolled out today noon UTC: - Add patch to fix sending of emails over SSL (without STARTTLS): * 0001-Fix-duplicate-authentication.patch * Fixes kde#388068, kde#387926 and boo#1073975 does ***NOT*** fix this issue for me. -- You are receiving this mail because: You are watching all bug changes.
