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.


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:

1 Like

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