verteiler nicht rfc-konform ?

["AS" <Sire_AS@gmx.de>]

ich habe ja die ganze zeit das problem, dass ich mit meinen mails
die threads zerreiße.
mir fehlt ein feld, welches references heißt,welches die
einzelnen mails zueinander ordnet.
ich habe mal etwas in den rfc´s gestöbert und heraus kam
folgendes:

5.2.2.2.  Fragmentation and Reassembly Example

   If an audio message is broken into two pieces, the first piece
might
   look something like this:

     X-Weird-Header-1: Foo
     From: Bill@host.com
     To: joe@otherhost.com
     Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
     Subject: Audio mail (part 1 of 2)
     Message-ID: <id1@host.com>
     MIME-Version: 1.0
     Content-type: message/partial; id="ABC@host.com";

                   number=1; total=2

     X-Weird-Header-1: Bar
     X-Weird-Header-2: Hello
     Message-ID: <anotherid@foo.com>
     Subject: Audio mail
     MIME-Version: 1.0
     Content-type: audio/basic
     Content-transfer-encoding: base64

       ... first half of encoded audio data goes here ...

   and the second half might look something like this:

     From: Bill@host.com
     To: joe@otherhost.com
     Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
     Subject: Audio mail (part 2 of 2)
     MIME-Version: 1.0
     Message-ID: <id2@host.com>
     Content-type: message/partial;
                   id="ABC@host.com"; number=2; total=2

       ... second half of encoded audio data goes here ...

   Then, when the fragmented message is reassembled, the
resulting
   message to be displayed to the user should look something like
this:

     X-Weird-Header-1: Foo
     From: Bill@host.com
     To: joe@otherhost.com
     Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
     Subject: Audio mail
     Message-ID: <anotherid@foo.com>
     MIME-Version: 1.0
     Content-type: audio/basic
     Content-transfer-encoding: base64

       ... first half of encoded audio data goes here ...
       ... second half of encoded audio data goes here ...

   The inclusion of a "References" field in the headers of the
second
   and subsequent pieces of a fragmented message that references
the
   Message-Id on the previous piece may be of benefit to mail
readers
   that understand and track references.  However, the generation
of
   such "References" fields is entirely optional.

   Finally, it should be noted that the "Encrypted" header field
has
   been made obsolete by Privacy Enhanced Messaging (PEM)
[RFC-1421,
   RFC-1422, RFC-1423, RFC-1424], but the rules above are
nevertheless
   believed to describe the correct way to treat it if it is
encountered
   in the context of conversion to and from "message/partial"
fragments.

was für mich im moment nichts anderes heißt, das der verteiler
sich darauf verläßt, das sowieso nur mail-readers, die mit
linux-distributionen ausgeliefert werden und das feld
"references" einsetzen, die nailinglist lesen. Aber dieses feld
ist nur optional und selbst wenn es vom reader unterstützt wird,
muss der verteiler sich der oben beschrieben übertragungsweise
bedienen.

schönen schrank auch :-(

gruß

Sire_AS