You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to be able to set up Maddy (along with Caddy and some other glue code) as a chatmail server that works with Delta Chat. In my local testing, Maddy already works pretty well, but it seems to be missing two features that would make it perform optimally as a chatmail server: IMAP QUOTA and IMAP CONDSTORE.
Quotas
Support for quotas would allow Delta Chat to display the storage used on the IMAP server. It would also allow chatmail server operators to restrict the amount of storage each user is allowed to occupy (for example, to avoid filling up the server's disk). Providing administrative controls to limit the storage growth is important to ensure a chatmail service is able to operate reliably. Providing a user interface to view those limits is also important, so that users are not blindsided by the quota.
CONDSTORE
Support for CONDSTORE is necessary for chat message (email) read status synchronization. This is not particularly important if a user only uses DeltaChat on one device, but it is critical if a user adds the same account to multiple devices: deltachat/deltachat-core#200
Note alternatives you considered and why they are not useful.
The existing tooling for setting up chatmail servers works great on Debian/Ubuntu, but having a bundled-together version of Maddy, Caddy, and a web tool for making accounts would make it much easier to set up chatmail servers in more places. (Especially if I'm able to successfully get all three tools to work together with https://gokrazy.org, which would make deployment extremely easy.)
Your idea for a solution
How your solution would work in general?
These IMAP extensions well-documented in their respective RFCs:
I expect that quota would be the easier of the two, because it would involve tracking a smaller amount of information. I do not have very much experience with IMAP, and no experience with Maddy's codebase, so I don't know how to recommend implementing either of these extensions. That said, I'm absolutely willing to help!
Regardless, there will need to be some way to configure the quota limits, and some way to track how much space has been used, which I suspect will require adjustments to go-imap-sql. Supporting CONDSTORE seems to require deeper changes, especially because it modifies the behavior of several other IMAP commands, and requires the server to track additional state per IMAP connection.
Note that some overly complicated solutions may be rejected because maddy is meant to be simple.
I'm willing to help with the implementation
The text was updated successfully, but these errors were encountered:
Support for CONDSTORE improves the performance of chat message (email) read status synchronization. This is not particularly important with few messages, but grows more impactful as the number of stored messages increases.
Without CONDSTORE support Delta Chat does not synchronize read status at all, there is no slower fallback.
Without CONDSTORE support Delta Chat does not synchronize read status at all, there is no slower fallback.
Ah, thank you for correcting my mistake! I wrote that based on a cursory look at the Delta Chat client code, and I apparently misunderstood how that part worked.
Use case
What problem you are trying to solve?
I would like to be able to set up Maddy (along with Caddy and some other glue code) as a chatmail server that works with Delta Chat. In my local testing, Maddy already works pretty well, but it seems to be missing two features that would make it perform optimally as a chatmail server: IMAP QUOTA and IMAP CONDSTORE.
Quotas
Support for quotas would allow Delta Chat to display the storage used on the IMAP server. It would also allow chatmail server operators to restrict the amount of storage each user is allowed to occupy (for example, to avoid filling up the server's disk). Providing administrative controls to limit the storage growth is important to ensure a chatmail service is able to operate reliably. Providing a user interface to view those limits is also important, so that users are not blindsided by the quota.
CONDSTORE
Support for CONDSTORE is necessary for chat message (email) read status synchronization. This is not particularly important if a user only uses DeltaChat on one device, but it is critical if a user adds the same account to multiple devices: deltachat/deltachat-core#200
Note alternatives you considered and why they are not useful.
The existing tooling for setting up chatmail servers works great on Debian/Ubuntu, but having a bundled-together version of Maddy, Caddy, and a web tool for making accounts would make it much easier to set up chatmail servers in more places. (Especially if I'm able to successfully get all three tools to work together with https://gokrazy.org, which would make deployment extremely easy.)
Your idea for a solution
How your solution would work in general?
These IMAP extensions well-documented in their respective RFCs:
I expect that quota would be the easier of the two, because it would involve tracking a smaller amount of information. I do not have very much experience with IMAP, and no experience with Maddy's codebase, so I don't know how to recommend implementing either of these extensions. That said, I'm absolutely willing to help!
I see there is already a quota extension for go-imap, and there appears to be some support for CONDSTORE in go-imap v2 as well as client support for CONDSTORE, but I haven't been able to get my head around either the status of go-imap v2 (somewhat mature, but unreleased?), or the status of updating Maddy to use go-imap v2 (using an old version of v1?).
Regardless, there will need to be some way to configure the quota limits, and some way to track how much space has been used, which I suspect will require adjustments to go-imap-sql. Supporting CONDSTORE seems to require deeper changes, especially because it modifies the behavior of several other IMAP commands, and requires the server to track additional state per IMAP connection.
Note that some overly complicated solutions may be rejected because maddy is meant to be simple.
The text was updated successfully, but these errors were encountered: