IMAP4 ID extension
Extracted elements (17)
The strict prohibition on using ID data for operational decisions is imperative so that the extension does not supplant IMAP's CAPABILITY mechanism with an ad-hoc approach where implementations guess each other's features based on claimed identity.
Intermediaries (proxies, firewalls) that modify an IMAP session must also change the ID command to advertise their presence. A firewall MAY block specific fields but SHOULD NOT disable the extension entirely or unconditionally remove the client or server list.
A firewall handling a CAPABILITY response MUST NOT allow the names of extensions to be returned to the client that the firewall has no knowledge of.
Field strings MUST NOT be longer than 30 octets, value strings MUST NOT be longer than 1024 octets, and implementations MUST NOT send more than 30 field-value pairs.
Implementations MAY send less information than available or no information at all in an ID command; such behavior may be useful to preserve user privacy.
Implementations MUST NOT make operational changes based on the data sent as part of the ID command or response. The ID command is for human consumption only and must not be used to improve performance, work around bugs, provide features, or deny service.
Implementations MUST NOT send false information in an ID command.
Implementations MUST NOT send the same field name more than once in an ID command or response.
Implementations MUST NOT use contact information from an ID response to submit automatic bug reports; implementations may include such information in a report but are prohibited from sending it without user authorization.
Defined field names include: name, version, os, os-version, vendor, support-url, address, date, command, arguments, and environment. Implementations are free to send none, any, or all of these; field strings are not case-sensitive.
The ID command allows a client to send a list of field/value pairs identifying its implementation to the server. The command is valid in any IMAP state. The client may send NIL instead of a list to request a server response without sending any client information.
The ID response is an untagged server reply containing a field/value parameter list describing the server implementation. A server MUST send a tagged ID response to an ID command, but MAY send NIL in place of the list.
Having implementation information about a client or server may make it easier for an attacker to gain unauthorized access due to known security holes in that implementation.
Server implementations must guard against attackers sending arbitrary garbage data via unauthenticated ID commands to fill up logs. Mitigations include truncating large responses, deduplicating responses by counter, and only logging authenticated users.
Some ID fields such as processor ID, Ethernet address, or other unique identifiers allow tracking of users in ways that violate privacy expectations; implementors must exercise extreme care when adding such fields.
The ID extension risks violating user privacy if misused. Clients and servers should notify users that they implement and enable the ID command, and should provide a method of disabling ID support entirely.
The ID command and response use a parenthesized list of alternating IMAP4 string field names and IMAP4 string-or-NIL values: `id_params_list ::= "(" #(string SPACE nstring) ")" / nil`. The id command is `"ID" SPACE id_params_list`.