Version: unspecified (using Devel) OS: Linux When Akonadi is configured to use sendmail for sending mail, it appears to pipe the message to the specified command with \r\n (carriage return, line feed) line endings. This is incorrect - in this mode sendmail expects native Unix line endings, i.e. \n (linefeed) alone. I cannot find a definitive source for the line ending requirement, and it is possible that traditional sendmail does not care. However, if the mail sender agent is actually Debian SSMTP, it does care about the line endings and unconditionally adds another \r (carriage return) to the transmitted message. Depending on the receiver, this can cause incorrect header or MIME boundary detection. Reproducible: Always Steps to Reproduce: Install SSMTP (ftp://ftp.debian.org/debian/pool/main/s/ssmtp) Configure the sending mail account to use /usr/lib/sendmail (a link to /usr/sbin/ssmtp) Send an email with attachments to a Google Mail account. Observe that the attachments are not recognised correctly, and the message body as displayed by gmail is something like: -- start ----------------------------------------------------------------- Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Message text -- Signature Content-Disposition: attachment; filename="xyzzy.gif" Content-Transfer-Encoding: base64 Content-Type: image/gif; name="xyzzy.gif" R0lGODlhcQBxAPQfAP//AP/MAMz/AMzMzMzMAMyZAMxmAJnMAJmZAJlmAGaZAGZmZmZmAGYzADNm (remainder snipped) -- end ----------------------------------------------------------------- Actual Results: Mail is received with additional line breaks, which cause the headers and MIME boundaries to be not interpreted correctly. Expected Results: Mail should be received correctly. The mail sending works correctly if SMTP is chosen for the mail sending agent. Trace of write on pipe between akonadi_maildispatcher_agent and SSMTP - \r\n line endings: [pid 25360] write(13, "From: Jonathan Marten <jjm@keelh"..., 10956) = 10956 | 00000 46 72 6f 6d 3a 20 4a 6f 6e 61 74 68 61 6e 20 4d From: Jo nathan M | | 00010 61 72 74 65 6e 20 3c 6a 6a 6d 40 6b 65 65 6c 68 arten <j jm@keelh | | 00020 61 75 6c 2e 6d 65 2e 75 6b 3e 0d 0a 54 6f 3a 20 aul.me.u k>..To: | | 00030 6d 61 72 74 65 6e 6a 6a 40 67 6d 61 69 6c 2e 63 martenjj @gmail.c | | 00040 6f 6d 0d 0a 53 75 62 6a 65 63 74 3a 20 54 65 73 om..Subj ect: Tes | | 00050 74 20 33 20 77 69 74 68 20 61 74 74 61 63 68 6d t 3 with attachm | | 00060 65 6e 74 0d 0a 44 61 74 65 3a 20 54 68 75 2c 20 ent..Dat e: Thu, | | 00070 30 36 20 4f 63 74 20 32 30 31 31 20 31 35 3a 34 06 Oct 2 011 15:4 | | 00080 39 3a 33 39 20 2b 30 31 30 30 0d 0a 4d 65 73 73 9:39 +01 00..Mess | | 00090 61 67 65 2d 49 44 3a 20 3c 31 33 33 38 35 36 39 age-ID: <1338569 | | 000a0 2e 67 6b 71 33 5a 55 38 57 6e 33 40 6b 65 65 6c .gkq3ZU8 Wn3@keel | | 000b0 68 61 75 6c 3e 0d 0a 4f 72 67 61 6e 69 7a 61 74 haul>..O rganizat | Capture of traffic between SSMTP and ISP mail server - line endings expended to \r\r\n: 0040 40 b9 46 72 6f 6d 3a 20 4a 6f 6e 61 74 68 61 6e @.From: Jonathan 0050 20 4d 61 72 74 65 6e 20 3c 6a 6a 6d 40 6b 65 65 Marten <jjm@kee 0060 6c 68 61 75 6c 2e 6d 65 2e 75 6b 3e 0d 0d 0a 54 lhaul.me .uk>...T 0070 6f 3a 20 6d 61 72 74 65 6e 6a 6a 40 67 6d 61 69 o: marte njj@gmai 0080 6c 2e 63 6f 6d 0d 0d 0a 53 75 62 6a 65 63 74 3a l.com... Subject: 0090 20 54 65 73 74 20 34 20 77 69 74 68 20 61 74 74 Test 4 with att 00a0 61 63 68 6d 65 6e 74 0d 0d 0a 44 61 74 65 3a 20 achment. ..Date: 00b0 54 68 75 2c 20 30 36 20 4f 63 74 20 32 30 31 31 Thu, 06 Oct 2011 00c0 20 31 36 3a 31 30 3a 35 32 20 2b 30 31 30 30 0d 16:10:5 2 +0100. 00d0 0d 0a 4d 65 73 73 61 67 65 2d 49 44 3a 20 3c 31 ..Messag e-ID: <1 00e0 34 37 31 30 36 33 2e 53 4c 65 4d 4e 49 30 66 62 471063.S LeMNI0fb 00f0 63 40 6b 65 65 6c 68 61 75 6c 3e 0d 0d 0a 4f 72 c@keelha ul>...Or
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584162, section "Summary": The simple satellite MTA ssmtp cannot properly handle e-mail messages already formatted with network ("DOS") line endings. Such messages may lose parts of the body, sent to the wrong recipicients, or have their last lines stripped for a related error.
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present? If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.