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.