77 lines
2.8 KiB
Plaintext
77 lines
2.8 KiB
Plaintext
MBOX-Line: From janssen at parc.com Thu Mar 8 11:25:40 2007
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bill Janssen <janssen@parc.com>
|
|
Date: Fri Jun 8 12:34:38 2018
|
|
Subject: [Imap-protocol] question on BODY[n.MIME]?
|
|
Message-ID: <07Mar8.112542pst."57996"@synergy1.parc.xerox.com>
|
|
|
|
I'm watching Thunderbird 1.5.0.10 do bad things with a home-grown
|
|
(from RFC 3501) IMAP server. I think our (mine and Thunderbird's)
|
|
understanding of the BODY[MIME] request might differ...
|
|
|
|
It seems that Thunderbird expects BODY[n.MIME] to return the entire
|
|
MIME part, while I think the spec says to return only a set of
|
|
headers, and only those headers specified in the MIME spec
|
|
("Content-Type", "MIME-Version", "Content-Transfer-Encoding",
|
|
"Content-Id", and "Content-Description"). In any case, TBird
|
|
seems to be building the message which it displays using the
|
|
headers as the body content!
|
|
|
|
Here's what I see on the wire:
|
|
|
|
It first fetches the BODYSTRUCTURE of the message, which in this
|
|
example has the UID 13. I've added a few newlines/spaces to make this
|
|
easier to read, but they aren't in the original. All lines are CR-LF
|
|
terminated. The {count} includes the CR-LFs.
|
|
|
|
C: 10 uid fetch 13 (bodystructure)
|
|
S: * 13 FETCH (bodystructure (("text" "plain" () NIL NIL "7BIT" 299 7)
|
|
("application" "pdf" ("name" "The_Noguchi_Filing_System.pdf") NIL NIL "base64" 824399)
|
|
"mixed" ("boundary" "13.0.xxx.xxxx.xxxx.4232.1161192893.766.2")) UID 13)
|
|
S: 10 OK UID FETCH completed
|
|
|
|
Thunderbird then fetches the header information (again, I've elided
|
|
some of it, and added some whitespace to make it easier to read):
|
|
|
|
C: 11 UID fetch 13 (BODY[HEADER] BODY[1.MIME] BODY[2.MIME])
|
|
S: * 13 FETCH (BODY[header] {1306}
|
|
Return-Path: [...]
|
|
Delivery-Date: Wed Oct 18 10:40:18 2006
|
|
Received: [...]
|
|
Received: [...]
|
|
Received: [...]
|
|
Received: [...]
|
|
Received: [...]
|
|
Received: [...]
|
|
Content-Type: multipart/mixed;
|
|
boundary="13.0.xxx.xxx.xxxx.4232.1161192893.766.2"
|
|
MIME-Version: 1.0
|
|
Subject: The Noguchi Filing System
|
|
To: [...]
|
|
From: janssen@parc.com
|
|
Message-Id: <06Oct18.103519pdt."511362(2)"@alpha.xerox.com>
|
|
Date: Wed, 18 Oct 2006 10:35:13 PDT
|
|
X-PARC-Posted: "Wed, Oct 18 10:35:26 2006 PDT7" <uir>
|
|
X-PARC-Posted: "Wed, Oct 18 10:36:09 2006 PDT7" <uironly>
|
|
|
|
BODY[1.mime] {28}
|
|
Content-Type: text/plain
|
|
|
|
BODY[2.mime] {104}
|
|
Content-Type: application/pdf; name=The_Noguchi_Filing_System.pdf
|
|
Content-Transfer-Encoding: base64
|
|
|
|
UID 13)
|
|
S: 11 OK UID FETCH completed
|
|
|
|
Am I misunderstanding the meaning of BODY[1.MIME], and sending back
|
|
the wrong data?
|
|
|
|
In this system, the mailbox message sequence numbers are the same as
|
|
the message UID numbers, so that's why you're seeing the same value in
|
|
both places. By the way, are there pitfalls with that design I'm not
|
|
seeing?
|
|
|
|
Bill
|
|
|