Bug 410848 - KMail drops a period in column 1 of HTML content
Summary: KMail drops a period in column 1 of HTML content
Status: REPORTED
Alias: None
Product: kmail2
Classification: Applications
Component: general (show other bugs)
Version: 5.7.3
Platform: openSUSE Linux
: NOR minor
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-12 12:06 UTC by David C. Bryant
Modified: 2019-08-12 12:13 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Raw email message copied from .local/share/... (13.75 KB, text/plain)
2019-08-12 12:06 UTC, David C. Bryant
Details
Same message, as saved from KMail (13.80 KB, application/mbox)
2019-08-12 12:07 UTC, David C. Bryant
Details
Same message, forwarded to GVTC and saved from KMail (15.86 KB, application/mbox)
2019-08-12 12:09 UTC, David C. Bryant
Details
Lines 154, 155, & 156 of the message, copied from att.net "Raw Message: display. (232 bytes, text/plain)
2019-08-12 12:13 UTC, David C. Bryant
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David C. Bryant 2019-08-12 12:06:20 UTC
Created attachment 122080 [details]
Raw email message copied from  .local/share/...

SUMMARY

This is an intermittent problem. Once in a while, when the character "." (ascii code x'2E') falls in column 1 (in an HTML-encoded string that has been broken into 77-byte chunks), KMail (or Akonadi, or the mail transport mechanism) drops that character from the file that is saved on disk. I only notice that this has happened if I actually try to click on the broken link. I get a 404 error in my browser, which I can usually fix pretty easily by just putting the missing "." back into the URL. 


STEPS TO REPRODUCE
1. Wait a while.
2. On average, 1 in 77 HTML-encoded links will be broken in this manner -- it only happens when X'2E' should appear right after a \n character, which tends to happen about 1/77th of the time (77-byte chunks).
3. When it happens, it's pretty obvious.

OBSERVED RESULT
I happened to catch this error red-handed today, so I'm filing this report while I have the evidence at hand. I have attached three files to this report. File "1565606331.R463.linux-f0mccolon2commas.txt" is the raw data from my ...akonadi_maildir_resource_1/inbox/cur folder. File "V E R I F Y.mbox" is the same thing, except that I saved it from the KMail File menu, so it has one extra line appended at the top of the file. File "V E R I F Y 2.mbox" is a copy of the same message that was forwarded from att.net to gvtc.com -- it has 24 extra header records because of the forwarding process. You can see that the "." is missing in the first two files (see lines 155 and 156, respectively), but present (for some odd reason) in the third one (see line 180). For what it's worth, I viewed the "Raw Message" in my browser at the att.net web site, and the "." is present. So it seems that the period got dropped during the SMTP transport step somehow -- it's at the server, but not in the local disk image.

EXPECTED RESULT
The "." should be present without fail.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 5.12.8
KDE Frameworks Version: 5.45.0
Qt Version: 5.9.4

ADDITIONAL INFORMATION
See the attachments.
Comment 1 David C. Bryant 2019-08-12 12:07:44 UTC
Created attachment 122081 [details]
Same message, as saved from KMail
Comment 2 David C. Bryant 2019-08-12 12:09:08 UTC
Created attachment 122082 [details]
Same message, forwarded to GVTC and saved from KMail
Comment 3 David C. Bryant 2019-08-12 12:13:08 UTC
Created attachment 122083 [details]
Lines 154, 155, & 156 of the message, copied from att.net "Raw Message: display.

I just put this in for grins. I copied it directly from the att.net web site.