Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Still searching for mime guru to look at headers

0 views
Skip to first unread message

Betsy Schwartz

unread,
Oct 25, 2004, 5:10:29 PM10/25/04
to
I posted before but didn't get any response. Please, can someone who is a
mime guru look at this, or point me towards a place where I might find a
mime guru? I would very much like to know whether this message below has
noncompliant headers or whether the problem is with Silkymail.

The message below is an example of one that that Silkymail can't parse
correctly. I'm pasting it quoted. Right off the top, it's got every line
terminated by a ctrl-M. It also has a Content-Type of multipart/mixed
with Content-Transfer-Encoding: Binary even though it's plain text.

But mostly I'm wondering if the boundary headers are correct.

Silkymail displays this as blank but quotes the contents in a "reply".
Messages with genuine attachments show up with their content displayed as
a text attachment

any clues welcome
thanks Betsy
~


> Return-Path: <nob...@icommons.harvard.edu>^M
> Received: from gsd.harvard.edu (localhost [127.0.0.1])^M
> by thoth (Cyrus v2.1.9) with LMTP; Fri, 01 Oct 2004 15:54:17 -
0400^M
> X-Sieve: CMU Sieve 2.2^M
> Received: from icommons.harvard.edu (icommons.harvard.edu
[128.103.60.22])^M
> by gsd.harvard.edu (8.12.6/8.12.6) with ESMTP id i91JsGxX024821
^M
> for <bet...@gsd.harvard.edu>; Fri, 1 Oct 2004 15:54:16 -0400
(EDT)^M
> Received: (from nobody@localhost)^M
> by icommons.harvard.edu (8.11.7p1+Sun/8.10.2) id i91JsBn15118;
^M
> Fri, 1 Oct 2004 15:54:11 -0400 (EDT)^M
> Message-Id: <200410011954...@icommons.harvard.edu>^M
> Content-Transfer-Encoding: binary^M
> Content-Type: multipart/mixed; boundary="_----------=_
1096660451137170"^M
> MIME-Version: 1.0^M
> X-Mailer: MIME::Lite 3.01 (F2.71; A1.48; B2.12; Q2.03)^M
> Date: Fri, 1 Oct 2004 19:54:11 UT^M
> From: "B. Kevin User" <ku...@gsd.harvard.edu>^M
> Bcc:^M
> Subject: 10/1: Test message #1 from iCommons Emailbal tool^M
> X-Filter-Version: 1.11a (thoth)^M
> X-Virus-Scanned: clamd / ClamAV version 0.67-1, clamav-milter version
0.67a^M
> ^M
> This is a multi-part message in MIME format.^M
> ^M
> --_----------=_1096660451137170^M
> Content-Disposition: inline^M
> Content-Length: 89^M
> Content-Transfer-Encoding: binary^M
> Content-Type: text/plain^M
> ^M
> Hi Betsy,^M
> This is a test message from the iCommons Emailbag tool. ^M
> - Kevin 3:53pm 10/1^M
> --_----------=_1096660451137170--^M
> ^M


Kjetil Torgrim Homme

unread,
Oct 25, 2004, 6:00:17 PM10/25/04
to
[Betsy Schwartz]:

>
> The message below is an example of one that that Silkymail can't
> parse correctly. I'm pasting it quoted. Right off the top, it's
> got every line terminated by a ctrl-M. It also has a Content-Type
> of multipart/mixed with Content-Transfer-Encoding: Binary even
> though it's plain text.

well, that's OK as long as the data can be transferred using SMTP (no
8-bit characters unless 8BITMIME has been negotiated, lines must be
shorter than 1000 octets). IMAP can support pure binary data in
messages without any restrictions.

> But mostly I'm wondering if the boundary headers are correct.

your quoted messages has been slightly corrupted, so it's impossible
to tell for sure. it looks OK to me, though. perhaps SilkyMail
doesn't expect multipart/mixed to have a single part? if so, that's a
bug in SilkyMail.
--
Kjetil T.

Hagrinas Mivali

unread,
Oct 25, 2004, 6:07:27 PM10/25/04
to

Betsy Schwartz wrote:
> I posted before but didn't get any response. Please, can someone who
> is a mime guru look at this, or point me towards a place where I
> might find a mime guru? I would very much like to know whether this
> message below has noncompliant headers or whether the problem is with
> Silkymail.
>
> The message below is an example of one that that Silkymail can't parse
> correctly. I'm pasting it quoted. Right off the top, it's got every
> line terminated by a ctrl-M. It also has a Content-Type of
> multipart/mixed with Content-Transfer-Encoding: Binary even though
> it's plain text.
>
> But mostly I'm wondering if the boundary headers are correct.

The boundary headers look fine, but I did not go through them and count up
the hyphens.

Although MIME allows a Content-Transfer-Encoding of binary, the assumption
is that since SMTP is seven bit, it will not be used with MIME through
conventional email. Also, there's a good chance that somebody who wrote an
MUA would account for quoted-printable in text/plain body parts, but not
expect binary as a value. Therefore, I would not expect the "binary" part
in there.

I don't think the email is technically illegal from MIME's standpoint, but I
would not be surprised if it did not get parsed correctly since a developer
may not have expected "binary."

Betsy Schwartz

unread,
Oct 28, 2004, 12:22:42 AM10/28/04
to
Thank you both! I will follow up with the developers. I apologize for the
corruption - the hyphens did indeed match at one time.

(I didn't post an example, but we have the same problem with multipart
messages that do have multiple parts)

Kyle Jones

unread,
Nov 9, 2004, 3:19:18 AM11/9/04
to
Betsy Schwartz <bet...@cs.umb.edu> wrote:
> I posted before but didn't get any response. Please, can someone who is a
> mime guru look at this, or point me towards a place where I might find a
> mime guru? I would very much like to know whether this message below has
> noncompliant headers or whether the problem is with Silkymail.
>
> The message below is an example of one that that Silkymail can't parse
> correctly. I'm pasting it quoted. Right off the top, it's got every line
> terminated by a ctrl-M. It also has a Content-Type of multipart/mixed
> with Content-Transfer-Encoding: Binary even though it's plain text.
>
> But mostly I'm wondering if the boundary headers are correct.

The problem is likely the ctrl-M's. They will cause problems
for mailers on UNIX-ish systems that expect message to arrive
already converted to the local line ending convention. If
your local system's line ending convention is linefeed only,
which is usual for UNIX-ish systems, then a line containing a
ctrl-M followed by a linefeed won't be considered an empty
line. An empty line is required to separate the header of a
message from the body. Not seeing an empty line, the mail
reader will continue reading through the body of the message
looking for the end of the header section until it reaches
the end of the message. Then it will start looking for a
message body but it's already been passed so the message will
be displayed as if it were empty.

0 new messages