30 lines
1.8 KiB
Plaintext
30 lines
1.8 KiB
Plaintext
MBOX-Line: From lyndon at orthanc.ca Sat Aug 11 08:43:32 2012
|
|
To: imap-protocol@u.washington.edu
|
|
From: Lyndon Nerenberg <lyndon@orthanc.ca>
|
|
Date: Fri Jun 8 12:34:48 2018
|
|
Subject: [Imap-protocol] BINARY + multiparts
|
|
In-Reply-To: <283BA59D-2B55-4E29-BD2F-D3C392D2E673@iki.fi>
|
|
References: <283BA59D-2B55-4E29-BD2F-D3C392D2E673@iki.fi>
|
|
Message-ID: <E7F9B601-2050-46A2-8A57-C945F3206026@orthanc.ca>
|
|
|
|
|
|
On 2012-08-10, at 19:39 PM, Timo Sirainen wrote:
|
|
|
|
> for a message that contains base64-encoded MIME parts. Do you change the MIME headers' Content-Transfer-Encoding value to "binary"? Or do you just return NO to the command? I implemented the former, but the RFC doesn't seem to require it.
|
|
|
|
If you convert the MIME part to binary encoding, you have to change the CTE header's value, else you have an invalid MIME object.
|
|
|
|
I was very uncomfortable about this sort of body content re-writing, and wanted to restrict binary fetch to terminal MIME body parts. In fact, I had thought that's how I had written the spec ? shows you how long it's been since I read the RFC. So either somebody talked me out of that restriction, or I just screwed up and forgot to include it in the document :-P
|
|
|
|
But given what's there today, "Fetch 1 Binary []" is a valid command in the fact of nested body content, so if it's not too hard to do the CTE rewrite, you might as well do it. But I would strongly advise client authors to restrict binary fetches to terminal body parts, as the behaviour of fetching non-terminals is going to be unpredictable.
|
|
|
|
--lyndon
|
|
|
|
-------------- next part --------------
|
|
A non-text attachment was scrubbed...
|
|
Name: signature.asc
|
|
Type: application/pgp-signature
|
|
Size: 858 bytes
|
|
Desc: Message signed with OpenPGP using GPGMail
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20120811/caf029a7/attachment.sig>
|