Smarter message size limit

Currently Delta Chat does not send messages which are larger than the recommeded message size (it’s 18 MB for me). I see this is because many email provider does not accept large attachments. I’d be really happy if somehow it supports large attachments. My email provider does not limit message size.

The ideal would be to detect the limit, but sadly mailserver softwares does not disclose it beforehand, just when you already uploaded a message to large.

An other workaround is to send multiple emails constituting a single large piece of message, altough it won’t be compatible with common email practices.

Thirdly, the user may set the limit as an app setting, but this is a bit annoying because 1 limit does not fit to all email providers, and setting this limit per each domain, per each contact is quite tiresome.

The best approach maybe is to keep not sending large messages but let users approve to sent them regardless: eg. by a “Send it anyway” button.

thanks for consideration.
Andreas.

5 Likes

I don’t know if this information could be inserted in the provider database, taking into account that some information the providers don’t even provide.
If it were possible, I think that the maximum size of the attachments that can be sent could be inserted in the header and consequently DC could vary the size of the attachment. :thinking:

hmm, hardly… which header? incoming and outgoing SMTP servers are often separated. an outgoing server can meaningfully insert such a header to indicate max message size to the outer world, but it’s the incoming server’s responsibility to manage this size limit. ok, they can be properly coordinated, but still, a past email from domain X is quite far removed from the workflow of sending email to domain X.

IMO it either should be indicated in the receiving SMTP server’s EHLO reply (besides other SMTP capabilities), or, in the worse case, in autoconfig xml (autoconfig xml is about setting up a MUA, so it only helps if you submit email directly to this SMTP server, not in generic server-to-server transaction).

…and it’d be a protocol extension which is difficult to introduce widely.

I think fragmenting the message is the best solution. It is probably not widely supported, but at least there is a standard which Delta Chat can implement to avoid reinventing the wheel:

2 Likes

it’s great that there is an rfc for it! i can not wait to implement it in my home-made MUA :slight_smile:

Hello people.

case 1: smarter message size limit with js
var str = 'Some very long string';
if(str.length > 10) str = str.substring(0,10); // limit in 10 characters
case 2: limit 255 characters with js
var str = 'Some very long string';
if(str.length > 255) str = str.substring(0,255); // limit in 255 characters

// or

var str2 = 'Some very long string';
if(str2.length > 1500) str = str.substring(1500); // limit in 1.500 characters

code-description It would be nice to limit the amount of text string - eg twitter limits it to 255 characters… we can do something similar to avoid large messages. Discord(app) limits… is 1500 characters.

or with html

  • <input maxlength="255">
  • <input maxlength="1500">

case 3: see how many messages the user has written

Another example would be… an example of a message limit… would be… gmail… gmail allows up to 350 messages per day. If you exceed 350 messages per day, you will be… blocked.

Note: As we can see in this use case… we have 2 limits… the amount of daily messages and the text size limit.

This will not prevent others from using another email client and sending you a large message anyway.

If you look at fediverse (Mastodon, Pleroma etc.) instead of Twitter, there are servers which enforce sending limit, but users from other servers can still send you a whole blog post in a single message.

Besides that, the problem discussed in OP is not about text messages, but about attachments which are megabytes (millions of characters) in size.

3 Likes

Hi link2xt.

This is not true… maybe… for this reason: - If you want to reduce the size of the email message, consider the 4 alternatives: temporary file service, temporary messaging service, limit the amount of characters in the message, limit the amount of messages in the message group

list of things to avoid large messages
  1. temporary file service: some temporary file services limit the amount to 2g as file-io/web-transfer etc or 100mb or 10mb as tempmail etc.
  2. temporary messaging service: some temporary messaging services limit the amount of sending messages to 10 messages per day, 100 messages daily as tempmail, temporary-email etc.
  3. limit the amount of characters in the message: 255 characters(twitter), 1.500 characters(Discord) etc.
  4. limit the amount of messages in the message group: you could check in a group of messages the total amount allowed, for example - gmail allows up to 350 contacts up to 350 messages.

as we can see, there are 4 ways to avoid large messages

But… temp files site has file size limit, file-io enforces 2gb file limit for upload. file-io-temporary-storage-in-delta-chat - this would be another way to avoid large files. (What I mean is that you would not send a file to the email, but only the temporary download link to be downloaded on your mobile.)

  • So… another way would be to… you can also limit the amount of file according to the space stored - I say in the download part.
  • So… another way would be to have an delta-chat-api service to check the file size before uploading.
  • So… another way… would be… protocols like ipfs, ftp, sftp etc can be used with some file limit. you could set the acceptable amount of file to transfer a file in ipfs/ftp/sftp for example.

As we can see, we have other ways to avoid a large file, either through the use of the delta-chat-api service, or through third-party services that have an acceptable limit on the amount of file or some network protocol that limits the amount of file to be sent.

this idea is interesting, fragmenting the messages… would be possible if these messages are binary.

The next version past 1.36 releases is going to have no limitation other than the provider’s one. You can already test it on the next nightly versions.

2 Likes