ghost
commented
3 years ago In fact, those who have the ability to send large attachments find themselves limited. Then with the new plug-in for simplebot you can get around the limit of the target provider. For example: I, who have Infomaniak as a provider, can send a 144 Mb attachment, the recipient can accept 25 Mb of attachments. I send the attachment to the bot and the bot returns me the link of the site where it uploaded the file. Now there is this 18 Mb limit. 😒
r10s
Use Case
Let me preface this with the following use case: journalists with mobile phones and unlimited data plans want to film a human rights violation in a dynamic situation, e.g. a protest.
They have pre-configured Delta Chat apps with temporary accounts and are in constant contact with their backoffice. Now say they film a few minutes of the situation and want to send the video to their backoffice, which has a temporary account on the same server.
The mail server is preconfigured to allow very, very large attachments, because the mail server admin is aware that large videos are important in such a situation; they know that because the accounts are temporary, the files will be deleted soon afterwards anyway.
Nonetheless, the journalist will encounter the following error (in my case reported with Linux because it doesn't really matter, there is an artificial restriction in the core, so the error will appear on any platform):
The Error Message
The Technical Side
The error is caused by this check: https://github.com/deltachat/deltachat-core-rust/blob/master/src/mimefactory.rs#L1068
it is an artificial client-side restriction on the message size. It's actually independent of any server-side restrictions and will trigger before the message is actually sent.
The topic of how to support large file transfer is also discussed in the forum: https://support.delta.chat/t/large-files-support/414/6
I quote @hpk42:
In the above-mentioned use case a cloud upload would also be possible; it's not optimal though, it's much more intuitive for journalists to just use a chat.
The Standards Argument
According to https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1.7, message size restrictions should be avoided if possible.
As handling the load of large email attachments is the responsibility of the mail server admin, they should decide how big attachments they accept, instead of artificial client-side limits.
But of course the optimization goal here is user's lives, not standard compliance.
The Real Life Argument
There are probably other use cases for which this restriction is improving user's lives, e.g. that their data plans don't get eaten by a large file which is then rejected by the mail server anyway (major frustration point). Apart from that I can imagine that the SMTP file transfer is not the most robust protocol, and will probably fail more likely, the larger the file; introducing more frustration. There are probably other reasons for this restriction as well?
Anyway, it seems like an arbitrary restriction. Do we really need it? It makes workarounds like the mail server admin's harder; it actively inhibits at least one use case which we try to optimize for.