[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
>[192.168.43.30])
> 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 [127.0.0.1])
> 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
>X-Keywords:
---------------- 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.
Dragon
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the Mailman-Users
mailing list