As a user I want have a validation before sending the request, or at least manage (display a nice error message) when size is exceeded.

[fabienmoyon]

current

User is able to send an email over the size limitation with a multiple attachments

Actual Result

User is able to send an email with multiple attachments that over the size limitation.
The email is saved to the Sent mailbox but not actually delivered to the recipient

Relate to this one #258

Expected Result

It should return a warning for over the size limitation and doesn't allow to send the email

As a user I want have a validation before sending the request, or at least manage (display a nice error message) when size is exceeded.

expected

James now allows to configure the maximum size for emails (sum of all attachments) allowed and fails when exceeded.

In the composer have a validation before sending the request, or at least manage (display a nice error message) when size is exceeded.

Related to https://ci.linagora.com/linagora/lgs/k8s/indus-team-backlog/-/issues/943#note_419214

[alagane]

I tried locally and got an email from James

What it should do is check the total file size before sending the mail asking if we are sure we want to send it, and it may fail?

[chibenwa]

Jmap rfc-8620 allow knowing max supported email size. Frontend can try detecting when this limit is exceeded. Like "sum attachment > max size". And the say " mail too big, please consider other means to share tgese files".

However it's not exact science as it do not account for base64 encoding, text bodies, headers, mime stuff, etc. Thus more importantly the underlying JMAP exception needs to be handled. Composer reopened with an explanation.

I am unsure how your james server is configured. It looks like no limit is set in the jmap layer but only at the mail processing layer.

[chibenwa]

So you :

• must configure jmap on james to enforce maximum size of submitted emails
• must handle the exception during the send, explain and reopen the composer
• could check jmap session to see what you are allowed to send and prevent submitting too big mails.

Sorry written from mobile, if you need detailed pointers (conf / jmap) feel free to ask.

[fabienmoyon]

And the goal of this issue it to validate and display to the user before sending the message that the max size is exceeded

[tanandy]

And the goal of this issue it to validate and display to the user before sending the message that the max size is exceeded

True as Benoit mentionned last time and you today, we need both client and server side validation.

No need to call the server if the size is already higher that what we allow in client

Note: you must also have to handle answer from the server (unexpected or not) correctly in the ui (in this issue, or create another one)

[chibenwa]

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.