[Large attachment mail] Send failure

[haftus98]

Description I created a draft mail with attachment of 19MB, long content. When I clicked send mail, the message prompted: "failure". I reopened the draft mail, now all the attachment and content were gone. I reloaded the draftmail box, the draftmail was gone.

Reproduce

1. Compose a mail
2. Attach to 19MB
3. Create a long content mail
4. Save to draft
5. Open draft mail, click send => message prompted "Failure"
6. Reopen the draftmail => Attachment and content are gone
7. Back to draft mail box => the draftmail is gone

Video

https://user-images.githubusercontent.com/97084773/201003408-85076dee-2fdf-4486-9dea-cbada1fef6fd.mp4

Environment IOS, gg chrome, v0.4.1

[chibenwa]

Not being able to upload big contents / email is fully normal.

Though the overall experience can be improved (error management)

Here the message should clearly state: the email you try to send is too big, and should reopen the composer.

Idem closing the composer (saving draft) fails but then I should from the notification be able to re-open the composer.

Also, the flutter composer should display an error when maxSizeAttachmentsPerEmail is exceeded. (show the attachment in reds, refuse to send, etc...).

[chibenwa]

Also

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.

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 maxSizeAttachmentsPerEmail: 50000000 (50 MB). 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.

TL;DR the JMAP server should advertise a limit that is lower that the one enforced (to take into account HTML bodies, encoding).

[chibenwa]

Prod? Or preprod @haftus98 ?

[chibenwa]

FYI in https://github.com/linagora/james-project/issues/4665 we would allow decreasing the size advertized in the session, and would decrease it to 10MB, this corner case where size would sit exactly in the middle would not happen anymore.

Though we can still let this ticket open (cc @hoangdat ) as obviously the error handling here can be improved.

I however reduce the severity of this bug.

[hoangdat]

obviously the error handling here can be improved.

What?

[hoangdat]

The title of this issue not describes the problem correctly. And WDYT when say something like that? @chibenwa. You have any bias with our error handling? What problem here? I pretty sure it is not related to 19 Mb or 10 Mb or anything else.

[chibenwa]

And WDYT when say something like that? @chibenwa. You have any bias with our error handling? What problem here? I pretty sure it is not related to 19 Mb or 10 Mb or anything else.

@hoangdat this is a pretty techie bug.

@haftus98 uploads 19.9MB worth of attachments. It is valid as per maxSizeAttachmentsPerEmail criteria. So the flutter app do not raise a warning upon edition / attaching. However James, when converting this to a real email, ends up with an email that is bigger than his true limit, configured at 25MB (because of base64 encoding, because of a VERRYYYY long body). James thus rejects the mail at 1:06 in @haftus98 video. The flutter app displays Message has been sent failure.

However from a user perspective:

• The error message is not even english. It should be Failure to send your message. Or something like this.

• The error message is not helpfull. James says "Why the message is rejected", namely though a SetError of type tooLarge which is pretty explicit. The Flutter app SHOULD, when this happens, say Failure to send your message, because it is too large.

  • Finally, user input is lost in this scenario and this is not really acceptable. Ideally when the sending fails we should at the very least offer to reopen the composer with the previous input. Idem when failing to save to draft. The error message would become Failure to send your message, because it is too large. [Re-open].

  I want also to make it clear: maxSizeAttachmentsPerEmail is a hint that frontend apps SHOULD follow, but they SHOULD still be able to manage failure to create too big of a mail (CF the quoted part of the RFC). In this example there is nothing preventing and allowing you to display an early warning if @haftus98 decides to copy and paste a shakespear novel in the body... You will have to handle backend exceptions in such case.

  (And yes, email specs can get tricky)

  Is this more clear @hoangdat ?