Interface JMAPAccountCapabilities

The maximum number of DataSourceObjects allowed per creation in a Blob/upload. Servers MUST allow at least 64 DataSourceObjects per creation.

The maximum size of the blob (in octets) that the server will allow to be created (including blobs created by concatenating multiple data sources together).Clients MUST NOT attempt to create blobs larger than this size.If this value is null, then clients are not required to limit the size of the blob they try to create, though servers can always reject creation of blobs regardless of size, e.g., due to lack of disk space or per-user rate limits.

An array of supported digest algorithms that are supported for Blob/get. If the server does not support calculating blob digests, then this will be the empty list. Algorithms in this list MUST be present in the "HTTP Digest Algorithm Values" registry defined by RFC 3230; however, in JMAP, they must be lowercased, e.g., "md5" rather than "MD5".Clients SHOULD prefer algorithms listed earlier in this list.

An array of data type names that are supported for Blob/lookup. If the server does not support lookups, then this will be the empty list. Note that the supportedTypeNames list may include private types that are not in the "JMAP Data Types" registry defined by this document. Clients MUST ignore type names they do not recognise.

A list of all the values the server supports for the "property" field of the Comparator object in an Email/query sort (see Section 4.4.2). This MAY include properties the client does not recognise (for example, custom properties specified in a vendor extension). Clients MUST ignore any unknown properties in the list.

The maximum depth of the Mailbox hierarchy (i.e., one more than the maximum number of ancestors a Mailbox may have), or null for no limit.

The maximum number of Mailboxes that can be can assigned to a single Email object. This MUST be an integer >= 1, or null for no limit (or rather, the limit is always the number of Mailboxes in the account).

The maximum total size of attachments, in octets, allowed for a single Email object. A server MAY still reject the import or creation of an Email with a lower attachment size total (for example, if the body includes several megabytes of text, causing the size of the encoded MIME structure to be over some server-defined limit).

Note that this limit is for the sum of unencoded attachment sizes. Users are generally not knowledgeable about encoding overhead, etc., nor should they need to be, so marketing and help materials normally tell them the "max size attachments". This is the unencoded size they see on their hard drive, so this capability matches that and allows the client to consistently enforce what the user understands as the limit.

The server may separately have a limit for the total size of the message [@!RFC5322], created by combining the attachments (often base64 encoded) with the message headers and bodies. For example, suppose the server advertises 50 MB:

maxSizeAttachmentsPerEmail: 50000000

The enforced server limit may be for a message size of 70000000 octets. Even with base64 encoding and a 2 MB HTML body, 50 MB attachments would fit under this limit.

The maximum length, in (UTF-8) octets, allowed for the name of a Mailbox. This MUST be at least 100, although it is recommended servers allow more.

If true, the user may create a Mailbox in this account with a null parentId. (Permission for creating a child of an existing Mailbox is given by the myRights property on that Mailbox.)

The number in seconds of the maximum delay the server supports in sending. This is 0 if the server does not support delayed send.

The set of SMTP submission extensions supported by the server, which the client may use when creating an EmailSubmission object (see Section 7). Each key in the object is the ehlo-name, and the value is a list of ehlo-args.