Subject: Content-Length not honored

From: Sebastian Hagedorn <[email-masked]>
Date: Tue, 26 Feb 2002 14:34:20 +0100

Hi,

I was caught unawares by a behavior of c-client that is quite 
disadvantageous in our situation. We've upgraded our central mail server 
and now use the UW versions of POP and IMAP whereas previously we'd been 
using Sun's SIMS 2.0 (yuck!).

Well, everything is fine except for an issue with bounces from Majordomo. 
These appear like this in the mailbox (standard mbox format):
NB they actually appear *without* the > in front of the "From"!

>From [email-masked] Tue Feb 26 12:15:22 2002
Return-Path: <[email-masked]>
Received: from mail1.rrz.Uni-Koeln.DE (localhost [127.0.0.1])
        by mail1.rrz.Uni-Koeln.DE (8.12.2/8.12.2) with ESMTP id 
g1QBD2jp023446
        (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 
verify=NOT)
        for <[email-masked]>; Tue, 26 Feb 2002 12:13:02 
+0100 (MET)
Received: (from daemon@localhost)
        by mail1.rrz.Uni-Koeln.DE (8.12.2/8.12.2/Submit) id g1QBD2eT023445;
        Tue, 26 Feb 2002 12:13:02 +0100 (MET)
Date: Tue, 26 Feb 2002 12:13:02 +0100 (MET)
Message-Id: <[email-masked]>
To: [email-masked]
From: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from 
[[email-masked]]
Content-Length: 3618

>From [email-masked] Tue Feb 26 12:12:50 2002
Received: from localhost.localdomain ([211.62.36.15])
        by mail1.rrz.Uni-Koeln.DE (8.12.2/8.12.2) with ESMTP id 
g1QB6Ujo020912;
        Tue, 26 Feb 2002 12:06:56 +0100 (MET)
Received: from gt40_[192.168.226.24] (A020-0677.DLL2.splitrock.net 
[209.254.218.169])
        by localhost.localdomain (8.11.0/8.11.0) with SMTP id g1QB5Lc06341;
        Tue, 26 Feb 2002 20:05:27 +0900
Received: from tcl.gr.jp by gt40 with ESMTP; Tue, 26 Feb 2002 06:03:25 -0500
Message-ID: <[email-masked]>
To: <[email-masked]>
From: [email-masked]
Subject: WHAT ARE THEY REALLY DOING ONLINE.                         21862
...

Both pine and the UW daemons treat these as two separate mails, whereas 
SIMS and e.g. ZMail (and obviously sendmail 8.12.2 as well) treat this as 
one message. Apparently the latter honor the Content-Length header where 
the former don't. Well, it's not part of RFC (2)822 ...

I don't really care who is right and who is wrong, but I need some kind of 
workaround because Majordomo list owners currently can't approve bounced 
mails the way they used to.

So I'd be grateful for a suggestion...

Gruß, Sebastian Hagedorn
--
Sebastian Hagedorn M.A. - Postmaster - RZKR-R1 (Flachbau), Zimmer 18
Zentrum für angewandte Informatik - Unversitätsweiter Service RRZK
Universität zu Köln / Cologne University - Tel. +49-221-478-5587

---

From: Mark Crispin <[email-masked]>
Date: Tue, 26 Feb 2002 15:47:15 -0800 (PST)

This topic is addressed in the UW IMAP FAQs:

Q: Why does a message sometimes get split into two or more messages on my
    SUN system?
A: This is caused by an interaction of two independent design problems in
    SUN mail software.  The first problem is that the "forward message"
    option in SUN's "mail tool" program includes the internal "From "
    header line in the text that it forwarded.  This internal header line
    is specific to traditional UNIX mailbox files and is not suitable for
    use in forwarded messages.
   The second problem is that the mail delivery agent assumes that mail
    reading problems will not use the traditional UNIX mailbox format but
    instead an incompatible variant that depends upon a "Content-Length:"
    message header.
   Content-Length is widely recognized to have been a terrible mistake,
    and is no longer recommended for use anywhere.
   One symptom of the problem is that under certain circumstances, a
    message may get broken up into several messages.
   I'm also aware of security bugs caused by programs that foolishly
    trust "Content-Length:" headers with evil values.
   To fix the mailer on your system, edit your sendmail.cf to change the
    Mlocal line to have the -E flag.  A typical entry will lool like:
        Mlocal, P=/usr/lib/mail.local, F=flsSDFMmnPE, S=10, R=20,
                A=mail.local -d $u
   This fix will also work around the problem with "mail tool", because
    it will insert a ">" before the internal header line to prevent it
    from being interpreted by mail reading software as an internal header
    line.

---

From: Sebastian Hagedorn <[email-masked]>
Date: Wed, 27 Feb 2002 10:54:18 +0100

> This topic is addressed in the UW IMAP FAQs:

Thank you very much. I could've sworn that I checked the FAQ, but obviously 
I didn't...
--
Sebastian Hagedorn
Ehrenfeldgürtel 156
50823 Köln
http://www.spinfo.uni-koeln.de/~hgd/

Winter is coming.

---

From: "Shawn Walker" <[email-masked]>
Date: Wed, 27 Feb 2002 17:52:45 -0600

How can I create a folder on the IMAP server with characters that
contains 8-bit characters?  We have some customers that can't create a
folder with a accent (ö).

Thanks,
Shawn

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Wed, 27 Feb 2002 16:08:32 -0800 (Pacific Standard Time)

On Wed, 27 Feb 2002, Shawn Walker wrote:
> contains 8-bit characters?

You don't/can't.

> We have some customers that can't create a
> folder with a accent ($B‹
(B.

The way to use non-ASCII characters in mailbox names is to use the
"modified UTF-7" convention described in RFC 2060.  Basically, you
represent the desired name as Unicode (which means converting from, say,
ISO 8859-1 to Unicode) and then follow the rules of modified UTF-7 to
represent the Unicode string as a 7-bit mailbox name.

8-bit characters in mailbox names are reserved for future use as UTF-8
mailbox names.  They are forbidden (and have been for over 5 years) in
order to exterminate legacy use for ISO 8859-1 names, Shift-JIS names,
etc.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.