Package: sendmail
Version: 8.12.3-7.1
Severity: important
Tags: patch
/usr/lib/sm.bin/mail.local does not escape any "From " lines, contrary
to what /usr/share/man/man8/mail.local.8.gz (man mail.local) says:
Individual mail messages in the mailbox are delimited by
an empty line followed by a line beginning with the string
``From ''. A line containing the string ``From '', the
sender's name and a time stamp is prepended to each deliv�
ered mail message. A blank line is appended to each mes�
sage. A greater-than character (``>'') is prepended to
any line in the message which could be mistaken for a
``From '' delimiter line (that is, a line beginning with
the five characters ``From '' following a blank line).
...
WARNING
mail.local escapes only "^From " lines that follow an
empty line. If all lines starting with "From " should be
escaped, use the 'E' flag for the local mailer in the
sendmail.cf file.
I feel that mail.local should escape "\n\nFrom " lines as documented:
not escaping them corrupts the documented structure of mbox files and
thus upsets many other packages that read mbox files. To demonstrate the
problem, send a message containing:
Hello there.
From here on mailx and some
others see a bogus message.
-----
Unfortunately, Debian policy
http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-mail-transport-agents
http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.3
http://www.debian.org/doc/packaging-manuals/fhs/fhs-5.8.html
does not define /var/mail/USER beyond "standard UNIX mailbox format".
See also:
http://www.ietf.org/internet-drafts/draft-hall-mime-app-mbox-04.txt
http://www.tldp.org/HOWTO/Mail-Administrator-HOWTO-3.html#ss3.5
-----
I propose that the Debian package sendmail be changed so as no longer to
use the CONTENTLENGTH option when building mail.local (set in
sendmail-8.13.3/debian/configure{,.ac}).
Using 'E' for Mlocal in /etc/mail/sendmail.cf works fine, escaping all
"From " lines. This may provide a crude workaround.
Otherwise, a trivial patch to sendmail-8.13.3/mail.local/mail.local.c could
allow quoting of "\n\nFrom " lines as documented, even with CONTENTLENGTH
defined. But that would give "worst of both worlds" thus would be useless:
Content-Length advocates would be unhappy with munged lines, detractors
would be unhappy with the header still present. The sole purpose of
CONTENTLENGTH is to get away from the quoting of "\n\nFrom " lines.
-----
File sendmail-8.13.3/mail.local/README says:
Defining CONTENTLENGTH (-DCONTENTLENGTH) will build a mail.local which
outputs a Content-Length: header. Solaris 2.3 and later will automatically
include Content-Length: support. ...
This assumption does not apply for Debian, many packages do not support
Content-Length (see below). It is bizarre that mail.local should even care
about Solaris 2.3, as the README starts with
This is not intended to be used on *stock* System V derived systems such as
Solaris ...
Neither the README nor the man page say that no "\n\nFrom " line quoting
is done with CONTENTLENGTH.
-----
A quick look at an ad-hoc selection of Debian mbox reading packages:
Package Support for Content-Length?
exim no
balsa yes
chaos yes
cronosii no
evolution yes
gnus yes
im yes
ipopd no
mailutils no
mailutils-pop3d no
mailx no
mew yes
mutt yes
nmh no
popa3d no
postilion no
pronto no
qpopper yes
solid-pop3d no
sylpheed no
teapop no
tkmail no
vm dodgy (depending on first message)
-----
There may be arguments for not quoting From lines, so as to preserve the
original message, for example:
http://bugs.debian.org/109171
However, sensible quoting allows the original message to be recovered:
http://www.qmail.org/man/man5/mbox.html
Anyway I fail to see what the fuss is about munging messages with quoted
>From lines. Much munging is done elsewhere: lines over 80 bytes are
wrapped, lines over 1kB broken up with "!\n"; line ending (UNIX NL vs DOS
CR/LF) conversion; 8-bit to 7-bit or quoted-printable conversion; skipping
of (rest of line from) NULL bytes; "dot" line quoting. These may (also)
happen at various (MX) MTAs, outside the control of sender or recipient; so
any attempt to preserve (plain-text, non-MIME) mail content exactly (e.g.
for cryptographic signing) is probably doomed anyway.
The sender may take care to send simple messages (short lines of fully
printable characters, no From or dot lines etc) to have some expectancy
(but no assurance) that the message body will be received intact; can do
this for any messages/files, automagically, with MIME.
I wonder how the munging of any Content-Length headers is acceptable.
Are headers generally "disposable": not considered essential, like
Subject and Reply-To? If the message had a Content-Length header: should
it be checked for correctness (and the message rejected if not)?
Could we please re-establish the principle that email is meant to be human
readable, and that while munging of messages is discouraged, any
transformations that preserve human readability (and MIME structure?) are
permitted?
-----
There may be arguments for not using Content-Length at all. Some
references:
http://www.netscape.com/eng/mozilla/2.0/relnotes/demo/content-length.html
http://groups.google.com/groups?hl=en&lr=&ie=ISO-8859-1&q=%22content-length%22+harmful
http://www.washington.edu/imap/documentation/BUILD.html
-----
Thanks,
Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux pisa.maths.usyd.edu.au 2.4.22-smssvr1.5.3 #1 SMP Wed Jun 23
13:01:39 EST 2004 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages sendmail depends on:
ii adduser 3.47 Add and remove users and groups
ii libc6 2.2.5-11.8 GNU C Library: Shared libraries an
ii libdb3 3.2.9-16 Berkeley v3 Database Libraries [ru
ii libldap2 2.0.23-6.3 OpenLDAP libraries.
ii liblockfile1 1.03 NFS-safe locking library, includes
ii libsasl7 1.5.27-3.1woody5 Authentication abstraction library
ii libssl0.9.6 0.9.6c-2.woody.7 SSL shared libraries
ii libwrap0 7.6-9 Wietse Venema's TCP wrappers libra
ii m4 1.4-14 a macro processing language
ii perl 5.6.1-8.8 Larry Wall's Practical Extraction
ii sysvinit 2.84-2woody1 System-V like init.
