IMAP BODYSTRUCTURE fields

1
votes

I am using GMail IMAP and I cannot understand some fields in my BODYSTRUCTURE.

"TEXT"-----------------------TYPE___________"IMAGE"-------------------------------------TYPE
"PLAIN"----------------------SUBTYPE________"JPEG"--------------------------------------SUBTYPE
("CHARSET" "utf-8")------ATTRIBUTES_____NIL--------------------------------------------ATTRIBUTES
NIL---------------------------CID_____________"email"---------------------------------------CID
NIL---------------------------DESCRIPTION____NIL--------------------------------------------DESCRIPTION
"QUOTED-PRINTABLE"-ENCODING______"BASE64"-------------------------------------ENCODING
11----------------------------SIZE____________352436---------------------------------------SIZE
2-----------------------------LINES
NIL--------------------------1?_____________ _NIL--------------------------------------------1?
NIL--------------------------2?______________("ATTACHMENT"("FILENAME" "..."))---2?
NIL--------------------------3?______________NIL---------------------------------------------3?

I would like to know what fields are these (1-3) and what data they are carrying.

2 I believe it is some kind of "role" field.

1
networkinggmailimap
Where is that diagram coming from? If you're using a specific language and IMAP API, please provide details. - Barmar
I create this diagram to picture data I have. First 7 fields and LINES are described in RFC 3501 - MKAROL
I think that's the extension data described in section 7.4.2. - Barmar
But it looks like GMail lose one field. 2 is disposition field so 1 should be MD5 and what about field 3(language or location)? - MKAROL

1 Answers

2
votes

2 is a part of the content-disposition header field. If c-d looks like this:

Content-Disposition: attachment; filename=foo; security-clearance=burn-before-reading

then you'll get attachment (filename foo security-clearance burn-before-reading). The content disposion is, roughly, whether you're supposed to treat a particular body part as inline (immediate display) or an attachment. There may be supplementary data, most often a suggested name.

The other fields are likely the same for the content-type field, the content-language field and a generic extension thing. All are optional, so a server can legally leave out the fourth (which, if I am allowed a digression, is quite sensible too, because that field is difficult to parse, difficult to test and hardly ever used).

This is defined in RFC 3501 page 83, and described on pages 76 and 77.