[Pkg-dspam-misc] Bug#384936: dspam LMTP does not obey line length restriction of 1000 chars

[Daniel Kahn Gillmor]

Package: dspam
Version: 3.6.8-2
Severity: important


dspam can violate the LMTP protocol on delivery by producing lines
longer than 1000 characters.  It can do this even if it is fed proper,
LMTP-compliant data as input.

I have a dspam setup listening on a unix socket via LMTP, and
delivering via LMTP to another socket. An e-mail is delivered to this
dspam instance in clean, LMTP-compliant, quoted-printable MIME.  dspam
then turns around to its receiving LMTP side, and spits out the data
transcoded to 8bit MIME.  This violates the LMTP protocol when the
8bit version of the data includes strings of text that are greater
than 1000 characters.

Why is this a problem?  Other mail transport agents aren't required to
handle lines longer than 1000 chars, so they may reject the message
coming out of dspam, though they wouldn't have rejected it had they
seen the original version.

LMTP is basically an extension of SMTP, and inherits it restrictions
and limitations.   section 4 of RFC 2033 (LMTP) states:

   The LMTP protocol is identical to the SMTP protocol SMTP [SMTP]
   [HOST-REQ] with its service extensions [ESMTP], except as modified by
   this document.

Section 4.5.3.1 of RFC 2821 (SMTP) states:

  text line
      The maximum total length of a text line including the <CRLF> is
      1000 characters (not counting the leading dot duplicated for
      transparency).  This number may be increased by the use of SMTP
      Service Extensions.

i have transcripts of an example session where i use socat to provide
both dspam's LMTP input [0] and the socket receiving deliveries from
dspam [1].  I'm posting them via http rather than including them in
this e-mail because i don't want the exact text to get garbled in
transmission by any interfering MTAs :/

Unfortunately, i don't have a fix for this problem yet.  One
reasonable approach would be for dspam to emit the message via LMTP
*exactly* as it was recieved, even if it transcoded it internally for
purposes of scoring.

A practical example where this causes problems: i've seen this
behavior cause mail to be lost when delivering via LMTP to a cyrus 2.1
imap daemon, which has an 8K incoming line buffer.  Cyrus bounces the
non-LMTP-compliant input from dspam, even though it would not have
bounced the message dspam received passed verbatim.

	--dkg

[0] http://lair.fifthhorseman.net/~dkg/src/dspam/busted-line-length/server-side
[1] http://lair.fifthhorseman.net/~dkg/src/dspam/busted-line-length/client-side

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages dspam depends on:
ii  adduser                     3.96         Add and remove users and groups
ii  libc6                       2.3.6-15     GNU C Library: Shared libraries
ii  libdspam7                   3.6.8-2      DSPAM is a scalable and statistica
ii  libldap2                    2.1.30-13+b1 OpenLDAP libraries
ii  procmail                    3.22-16      Versatile e-mail processor
ii  sensible-mda                8.13.7-2     Mail Delivery Agent wrapper

Versions of packages dspam recommends:
pn  clamav-daemon                 <none>     (no description available)
ii  dspam-doc                     3.6.8-2    Documentation for dspam

-- no debconf information