[Mailman-Users] [Fwd: archive emails are garbled]

Dragon dragon at crimson-dragon.com
Wed Sep 20 01:08:04 CEST 2006

Justin Zygmont sent the message below at 15:28 9/19/2006:

>ok, thanks.  Here is a paste of the message sources.  These both don't
>show up as HTML in thunderbird for some reason, I guess mailman may not
>be the cause?  Messages below were each shortened to save size.
>Emailed directly to me:
>  From - Tue Sep 19 14:51:50 2006
>X-Account-Key: account2
>X-UIDL: 1154544464.3663
>X-Mozilla-Status: 0001
>X-Mozilla-Status2: 00000000
>Return-Path: <jbill at cityfone.net>
>X-Original-To: justin at cityfone.net
>Delivered-To: justin at cityfone.net
>Received: from citybillingcityfone.net (citybilling.cityfone.local
>         by citysupport.cityfone.local (Postfix) with ESMTP id A8CA12543C1
>         for <justin at cityfone.net>; Tue, 19 Sep 2006 14:50:05 -0700 (PDT)
>Received: from citybilling.cityfone.local (localhost [])
>         by citybillingcityfone.net (8.13.4+Sun/8.13.3) with ESMTP 
> id k8JLovlg007676
>         for <justin at cityfone.net>; Tue, 19 Sep 2006 14:50:57 -0700 (PDT)
>Received: (from jan at localhost)
>         by citybilling.cityfone.local (8.13.4+Sun/8.13.3/Submit) id 
> k8JLovKo007675
>         for justin at cityfone.net; Tue, 19 Sep 2006 14:50:57 -0700 (PDT)
>Date: Tue, 19 Sep 2006 14:50:57 -0700 (PDT)
>From: jbill at cityfone.net
>Message-Id: <200609192150.k8JLovKo007675 at citybilling.cityfone.local>
>X-Authentication-Warning: citybilling.cityfone.local: jan set sender to
>jbill at cityfone.net using -r
>To: justin at cityfone.net
>Subject: test
>X-IMAPbase: 1154544464 3663
>Status: O
>X-UID: 3663
>Content-Length: 3344
---------------- End original message. ---------------------

The most immediate problem I see is that these messages are missing 
any sort of MIME headers (as defined in RFC2045). Without those 
headers, there is no definitive way for the mail client to know what 
the content is. Some MUAs will then default to plain-text and not try 
to even guess what the content type is. Some (like Eudora which I 
use) may detect the HTML structure of the message body and render it.

I am curious how you are creating these messages, are you composing 
them in an MUA in HTML format or are you cutting and pasting an HTML 
document from another editor into the message body? If the latter, 
you are not going to get the correct headers to identify the message 
content to a MIME compliant MUA. If the former, your MUA should be 
inserting these headers correctly.

As stated in section 1 of RFC2046:

    The first document in this set, 
<http://www.faqs.org/rfcs//rfcs/rfc2045.html>RFC 2045, defines a 
number of header
    fields, including Content-Type. The Content-Type field is used to
    specify the nature of the data in the body of a MIME entity, by
    giving media type and subtype identifiers, and by providing auxiliary
    information that may be required for certain media types.  After the
    type and subtype names, the remainder of the header field is simply a
    set of parameters, specified in an attribute/value notation.  The
    ordering of parameters is not significant.

    In general, the top-level media type is used to declare the general
    type of data, while the subtype specifies a specific format for that
    type of data.  Thus, a media type of "image/xyz" is enough to tell a
    user agent that the data is an image, even if the user agent has no
    knowledge of the specific image format "xyz".  Such information can
    be used, for example, to decide whether or not to show a user the raw
    data from an unrecognized subtype -- such an action might be
    reasonable for unrecognized subtypes of "text", but not for
    unrecognized subtypes of "image" or "audio".  For this reason,
    registered subtypes of "text", "image", "audio", and "video" should
    not contain embedded information that is really of a different type.
    Such compound formats should be represented using the "multipart" or
    "application" types.


  Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)

More information about the Mailman-Users mailing list