CODEWITHSUNDEEP
network-programminggmailimap
MKAROL
MKAROL

Reputation: 316

IMAP BODYSTRUCTURE fields

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.

Upvotes: 1

Views: 453

Answers (1)

arnt
arnt

Reputation: 9685

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.

Upvotes: 2

Related Questions