Your message dated Tue, 15 Jul 2014 01:33:47 +0000
with message-id <e1x6rcp-0005bc...@franck.debian.org>
and subject line Bug#584162: fixed in ssmtp 2.64-8
has caused the Debian Bug report #584162,
regarding ssmtp: Partial loss of message body, sending message to wrong
recipicients
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
584162: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584162
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: ssmtp
Version: 2.64-4
Severity: important
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.
Versions affected:
2.62 (Debian lenny 2.62-3)
2.64 (Debian testing 2.64-4)
Other versions not tested.
Background:
In the *ix world, line endings are marked by the line feed ("\n")
character only. In line-based network communication like SMTP
however, the sequence required for that is carriage return - line feed
("\r\n"). Therefore an injecting MTA must take care this requirement
is met. There is no rule - or none I am aware or could think of -
that forbids the application from already doing that conversion.
Therefore the MTA /must/ do the conversion only if required. The
latter is at least a consequence of the robustness principle.
Details:
The ssmtp MTA is completely unaware of \r\n line endings, they are
treated as if \r was a character without any special meanings at all.
For all messages that are piped to ssmtp with network line endings,
this has a lot of consequences:
1. The empty line separating header and body, technically the first
\r\n\r\n sequence is not detected as such. Instead, this and all
lines of the body are treated as header lines, and just due to
ssmtp's liberal understanding of an e-mail header, no harm is done
in general.
2. With the "From:" header line as exception, all lines read from
stdin are still converted into "network", creating line endings
with a duplicated CR character, i.e. \r\r\n. The receiving MTA
will hopefully deal with that (Postfix does, other not tested).
3. If ssmtp was called with the "-t" paramater (quite common), a line
in the body that begins with the characters "To:", "Bcc:" or "CC:"
(in arbitrary capitalisation) is treated as a recipicient's
specification and ssmtp will send a copy of the message to that
address. This could happen in an e-mail reply where the MUA puts
the original addressing information into the body (i.e. that
"-----Original Message-----" stuff). More things happen if the
line after such a line begins with a space.
Lines beginning with "From:" are appearently stripped, I didn't
investigate why precisely.
4. If a longer paragraph, roughly 2000 characters, is indented by one
or more space characters, this text will be treated as a single,
"folded" header line. However, when sending out header lines, only
the first 2048 characters are actually printed, the rest silently
dropped. This will cut out text out the body right in the middle
of the message.
5. On a related note, if the last line of the message is piped without
a line ending, this line will be discarded. If that line begins
with a space character, also all previous lines are lost up to and
including the first line that is empty or begins with a non-space
character.
How to repeat:
See the attached tar ball. It contains three messages that are not
handled properly if piped to "/usr/sbin/ssmtp -oi -t". I suggest
to use a packet sniffer to verify as the receiving MTA may alter
line endings.
How to fix:
* The header_parse function needs a major re-write.
* The standardise function needs to be \r-aware, this is rather easy.
* Document the limit of logical header lines in the manpage.
Usually I provide patches to ease fixing but the amount of changes
that are required for header_parse leave me in the feeling this should
be done upstream.
Cheers,
Christoph
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.32.13 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages ssmtp depends on:
ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy
ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib
ii libgnutls26 2.8.6-1 the GNU TLS library - runtime libr
ssmtp recommends no packages.
ssmtp suggests no packages.
-- Configuration Files:
/etc/logcheck/ignore.d.server/ssmtp [Errno 13] Permission denied:
u'/etc/logcheck/ignore.d.server/ssmtp'
-- debconf information:
* ssmtp/hostname: localhost
* ssmtp/root: postmaster
* ssmtp/rewritedomain:
ssmtp/overwriteconfig: true
ssmtp/mailname:
* ssmtp/port: 25
* ssmtp/mailhub: localhost
* ssmtp/fromoverride: false
ssmtp-test.tar.gz
Description: Binary data
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
Source: ssmtp
Source-Version: 2.64-8
We believe that the bug you reported is fixed in the latest version of
ssmtp, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 584...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Anibal Monsalve Salazar <ani...@debian.org> (supplier of updated ssmtp package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Tue, 15 Jul 2014 01:49:18 +0100
Source: ssmtp
Binary: ssmtp
Architecture: source mips
Version: 2.64-8
Distribution: unstable
Urgency: medium
Maintainer: Anibal Monsalve Salazar <ani...@debian.org>
Changed-By: Anibal Monsalve Salazar <ani...@debian.org>
Description:
ssmtp - extremely simple MTA to get mail off the system to a mail hub
Closes: 584162
Changes:
ssmtp (2.64-8) unstable; urgency=medium
.
* Fix "Partial loss of message body, sending message to wrong recipicients".
Reported by Christoph Biedl <debian.a...@manchmal.in-ulm.de>.
Patch by "Daniel Richard G." <sk...@iskunk.org>.
Add ssmtp-bug584162-fix.patch.
Closes: #584162.
* Refresh patches.
* Standards-Version: 3.9.5.
Checksums-Sha1:
f20e3cafb1ac86181387c9eba28828f485c013ac 1819 ssmtp_2.64-8.dsc
6fdc51ffccfb875d574a7c7e84a3d4905fb164fc 37916 ssmtp_2.64-8.debian.tar.bz2
ec4a227589967f03f73f167b686b9821eb1bb0c8 55242 ssmtp_2.64-8_mips.deb
Checksums-Sha256:
0b115e9b555a267d35d1fc81b7a245f0a1104085ead361b862b913836d961238 1819
ssmtp_2.64-8.dsc
2ed9caf0a14d4d5a44837a4a76cd5c9a52e527e2eb7a300eb328d90cc97917f0 37916
ssmtp_2.64-8.debian.tar.bz2
1c8be2c3b5353a66750db9ca3d81fcf3c792dcf36f1e635d25110fc6496135af 55242
ssmtp_2.64-8_mips.deb
Files:
7232acf927e5c4a8c088937f83dae7ee 55242 mail extra ssmtp_2.64-8_mips.deb
2d9151bc46be620c9e078eaa2a836908 1819 mail extra ssmtp_2.64-8.dsc
4a7d0e81a160b32dff2311eedfb3e35d 37916 mail extra ssmtp_2.64-8.debian.tar.bz2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJTxIH/AAoJEHxWrP6UeJfYtBAP/02AOrvJ02qIsM0ja45e5dr2
1vB7SFCq5pbdUBLxWFCZGCn3Ha0OTfdZJkhYk/bgZrpABWkn3Gw5COAxggsV2jOb
2+c1Ae4pOFaifQrT5x0FwueEiBExPZvLddcCj5E+AsfnipHmUvyF49ZZE1/S54WF
+mKP8rodhV4LP1eme73DK733zbiuPsvbHl01/yzGuaDx3XWm43QBSVRBl9myrDyM
uFSstFljefKqwhUHvmjxr2h4PDJ1ap8yHjJvBX8/uM3Dqp2Scj4yE7RUZD5v3IlB
I9kUXy2fiAZi/WMPEtmrl+wjJekPUSMrNCXAQMuf8dqBHfkiqKpfT8UjNIeyzdLU
n0USGawAXINkIq7LhMAie885+mlZPlSNBhMaZA72RXN7kuqeMtjj93HJycB67n0i
fOXs5lmCUKV1DUOfDbNKrJ589yG4mledRA77WhPsdnaltsFBtx8qAf6tX3oWf/hb
sWRuBFI0lumD3m0V3Ih0OH41Rr4Cg9pfNwAxwXExnM3KEx1get24SwNLT1iRD6WJ
57iXf41DteJUpWtw60lC/6ctlzuIXub3oyhtyGZr48E8NPuqblNrhaAKILQm3raN
gv0tnGmJkDmQxbgTd2QqIlxSVNt0QmeNygMpXBgfaSiLbX1DnkigMvG+YySPpqVI
kbvojq6cdNUbRv/8O6wU
=75y/
-----END PGP SIGNATURE-----
--- End Message ---
