mailing list archives

I'm working on parsing email to construct BODYSTRUCTURE response back to
client.

I put together a simple email with some text, image and an attachment on
gmail, so I can have a guideline by comparing its response back to RFC.
Here's the response :

 

* 35 FETCH (BODYSTRUCTURE (((("TEXT" "PLAIN" ("CHARSET" "big5") NIL NIL
"7BIT" 860 14 NIL NIL NIL)("TEXT" "HTML" ("CHARSET" "big5") NIL NIL
"QUOTED-PRINTABLE" 4347 63 NIL NIL NIL) "ALTERNATIVE" ("BOUNDARY"
"----=_NextPart_002_0025_01CE5E06.E9940610") NIL NIL)("IMAGE" "PNG" ("NAME"
"image001.png") "<image001.png@01CE5E06.E9517ED0>" NIL "BASE64" 231788 NIL
NIL NIL) "RELATED" ("BOUNDARY" "----=_NextPart_001_0024_01CE5E06.E9940610")
NIL NIL)("IMAGE" "PNG" ("NAME" "DNS_MX_RECORD.png") NIL NIL "BASE64" 73572
NIL ("ATTACHMENT" ("FILENAME" "DNS_MX_RECORD.png")) NIL) "MIXED" ("BOUNDARY"
"----=_NextPart

_000_0023_01CE5E06.E9940610") NIL NIL))

 

However, when I tried to match up the fields with RFC, it seemed to be
missing an extension data item or am I misinterpreting the RFC?

For the non-multipart body part, I thought the format should be :

 

body-type body-subtype (parenthesized list of parameter) body-id body-desc
body-encoding body-size

 

if body-type = "text" then follow by <number of lines in body>

if body-type = "message" and body-subtype = "rfc822" then follow by
envelope, body structure, number of lines in message

 

lastly, follow by 4 extension data items : MD5, body disposition, body
language, body location

 

so, shouldn?t the first part look like this instead?

 

("TEXT" "PLAIN" ("CHARSET" "big5") NIL NIL "7BIT" 860 14 NIL NIL NIL NIL)
<--- I added body location data item

 

Also, I couldn't figure out what are the remaining fields for the multipart.
In my example above, what do the last 2 NIL represent after "MIXED"
("BOUNDARY" "----=_NextPart

_000_0023_01CE5E06.E9940610")?  I thought for multipart, it also follows by
4 extension data?

 

 

Thank you for your help~~

 

Helen

 


======================================
Powered by Rainbow Mail Server 6.0

?????????????????????????????????????????????????????????????????????????????????????
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Please consider the environment before printing this email.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130611/2ed1d2fc/attachment.html>

On Tue, Jun 11, 2013 at 10:50 AM, ??? <ayluen@i-freelancer.net> wrote:

> lastly, follow by 4 extension data items : MD5, body disposition, body
> language, body location
>
>
>
No, in the Formal Syntax (and if Mark were still here, he'd be pointing out
that the Formal Syntax is essential reading), it says:

body-ext-1part  = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
                  [SP body-fld-loc *(SP body-extension)]]]
                    ; MUST NOT be returned on non-extensible
                    ; "BODY" fetch

So implementations can supply only the MD5, for example - but if they
supply the location, they must also supply MD5, description, and language
first.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130611/7ef35ca6/attachment.html>

Hi Dave,

 

I?m still a bit puzzled, hopefully you could help me out.  I was studying a thread posted long time ago.  In that post, Mark corrected a bodystructure response.  

He put 4 NILs in the positions which I thought were for extension data.

 

Here is the thread I was referring to :

 

http://mailman2.u.washington.edu/pipermail/imap-uw/2005-November/000287.html

 

but according to your previous reply, the first non-multipart can look like this :

 

("TEXT" "PLAIN" ("CHARSET" "BIG5") NIL NIL "7BIT" 860 14 NIL)

 

Where the last NIL stands for MD5 (the rest 3 are optional)?

 

 

Thank you for being patient with me, I know my question sounds like a newbie as I?m trying to grasp RFC reading and IMAP little by little?.

 

Helen

 

 

From: Dave Cridland [mailto:dave@cridland.net] 
Sent: Tuesday, June 11, 2013 6:46 PM
To: ???
Cc: IMAP Protocol Interest List
Subject: Re: [Imap-protocol] Question on BODYSTRUCTURE

 

 

 

On Tue, Jun 11, 2013 at 10:50 AM, ??? <ayluen@i-freelancer.net> wrote:

lastly, follow by 4 extension data items : MD5, body disposition, body language, body location

 


No, in the Formal Syntax (and if Mark were still here, he'd be pointing out that the Formal Syntax is essential reading), it says:

 

body-ext-1part  = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang

                  [SP body-fld-loc *(SP body-extension)]]]

                    ; MUST NOT be returned on non-extensible

                    ; "BODY" fetch

 

So implementations can supply only the MD5, for example - but if they supply the location, they must also supply MD5, description, and language first.

 

Dave.


======================================
Powered by Rainbow Mail Server 6.0

?????????????????????????????????????????????????????????????????????????????????????
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Please consider the environment before printing this email.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130613/d08736f9/attachment.html>

On Thu, Jun 13, 2013 at 3:45 AM, ??? <ayluen@i-freelancer.net> wrote:

> Hi Dave,****
>
> ** **
>
> I?m still a bit puzzled, hopefully you could help me out.  I was studying
> a thread posted long time ago.  In that post, Mark corrected a
> bodystructure response.  ****
>
> He put 4 NILs in the positions which I thought were for extension data.***
> *
>
> ** **
>
> Here is the thread I was referring to :****
>
> ** **
>
>
> http://mailman2.u.washington.edu/pipermail/imap-uw/2005-November/000287.html
> ****
>
> **
>

Yes; he's correcting other things, and he's including all the optional data
set to NULL (because that's what his library chooses to do).


>  **
>
> but according to your previous reply, the first non-multipart can look
> like this :****
>
> ** **
>
> ("TEXT" "PLAIN" ("CHARSET" "BIG5") NIL NIL "7BIT" 860 14 NIL)****
>
> ** **
>
> Where the last NIL stands for MD5 (the rest 3 are optional)?****
>
> **
>

That seems valid by RFC 3501 to me, yes.

Though I'm surprised that BIG5 can be 7-bit encoded.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130613/d35cb219/attachment.html>