Email/set create should use tooLarge when attempt to create an oversized mail

[chibenwa]

linagora/esn-frontend-inbox#537 (comment)

Set email.send.max.size in jmap.properties, eg email.send.max.size=20M

CF https://github.com/apache/james-project/blob/master/server/apps/distributed-app/docs/modules/ROOT/pages/configure/jmap.adoc

Then in JMAP you can read the session object to retrieve that value on client side: https://jmap.io/spec-mail.html#additions-to-the-capabilities-object

maxSizeAttachmentsPerEmail: UnsignedInt 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.

And finally the error that should be returned when the size is exceeded is a tooLarge SetError as defined in https://jmap.io/spec-core.html#set

Re-reading James tests this morning I realize that we sadly don't use the specific tooLarge error set but rather relies on the generic invalidArguments. Cf https://github.com/apache/james-project/blob/413983cebf14265c5b18ecb682faecff503a7ba7/server/protocols/jmap-rfc-8621-integration-tests/jmap-rfc-8621-integration-tests-common/src/main/scala/org/apache/james/jmap/rfc8621/contract/EmailSetMethodContract.scala#L1422 . We'll fix that.