Extended URLFETCH for Binary and Converted Parts
Extracted elements (20)
The original URLAUTH URLFETCH command returns encoded data without sufficient metadata to decode, which is suitable for mail relay use cases (e.g., BURL) but not for non-mail applications (e.g., streaming) that require access to the actual decoded content and media type.
If the URL is invalid or the referenced part does not exist, the server returns NIL instead of a metadata parenthesized list, matching the behavior of the unextended URLAUTH command.
Unlike the CONVERT extension, BODYPARTSTRUCTURE in URLFETCH responses is not appended with a part specifier, because the part is already implicit in the URL.
Data containing NUL octets MUST be transferred using the literal8 syntax. Otherwise, content SHOULD use nstring encoding.
If a client issues a url-fetch-simple (unenclosed URL with no parameters), the server MUST respond with urldata-simple.
Metadata items MUST NOT appear more than once per URL requested, and clients MUST NOT request both BINARY and BODY in the same URL fetch.
Servers MUST understand all identity content transfer encodings defined in MIME (RFC 2045), as well as the transformation encodings Base64 and Quoted-Printable.
If BINARY decoding is not possible (e.g., an unknown content transfer encoding), the BINARY response item MAY contain NIL rather than the decoded content.
The BINARY parameter requests data with any Content-Transfer-Encoding removed. Data containing NUL octets MUST be transferred using the literal8 syntax defined in the BINARY extension (RFC 3516).
The BODY parameter requests data as-is, with content transfer encoding still applied, providing equivalent functionality to the unextended URLAUTH URLFETCH command.
The BODYPARTSTRUCTURE parameter requests metadata about the data contained in the response, as defined in the CONVERT extension (RFC 5259), reflecting any conversions or decoding that have taken place.
The BODYPARTSTRUCTURE response element reflects any conversions or decoding that have taken place, showing an identity encoding when BINARY is also requested.
The extended URLFETCH command encloses each URL and its associated parameters in a parenthesized list. When a URL is sent unenclosed or with no parameters, the command behaves exactly as specified in URLAUTH.
The URLAUTH=BINARY capability string signals that a server supports the extended URLFETCH command with optional per-URL parameters for binary and converted parts.
The URLFETCH response is extended to include, following the URL, a series of parenthesized metadata elements: BODYPARTSTRUCTURE, BINARY, and/or BODY, each reflecting the state of data after any server-side processing.
IANA added the URLAUTH=BINARY capability to the IMAP4 capabilities registry. IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC.
Fetching metadata about content pointed to by a URL (such as original filename and user-supplied description) allows an attacker to discover more about the content than was previously possible via the unextended URLFETCH. The additional value to an attacker is marginal and applies only to URLs for which the attacker lacks direct access, such as those produced by URLAUTH.
The extended URLFETCH command syntax uses url-fetch-ext = '(' url-full *(SP url-fetch-param) ')', where url-fetch-param is one of BODY, BINARY, BODYPARTSTRUCTURE, or an atom.
The url-meta-binary field encodes the BINARY response as either nstring or literal8. If the content contains a NUL octet, literal8 (prefixed with ~{length}) MUST be used; otherwise nstring SHOULD be used. On decoding error, NIL is used.
The URLFETCH response uses urldata-ext = SP url-full url-metadata, where url-metadata = 1*(SP '(' url-metadata-el ')'), containing one or more of BODYPARTSTRUCTURE, BINARY, or BODY elements.