JMAP support

[andris9]

I don't have time to work on this right now but JMAP is something that probably should be considered. IMAP is not so great for web clients.

[titanism]

Perhaps https://github.com/josephg/mime-to-jmap could be useful

[titanism]

Also see IMAP to JMAP https://github.com/stalwartlabs/imap-to-jmap

[andris9]

JMAP is completely off the table for now.

[titanism]

@andris9 do you feel this is from lack of adoption or technical resources necessary to implement (or both)? I figured this was the case

[andris9]

The main reason is that WildDuck already has an HTTP API, so adding JMAP wouldn't give much benefit. It would also be a huge undertaking. JMAP is more than 10 years old, and there is almost no adoption at all (Cyrus/Fastmail doesn't count as they are behind the spec, so it's Stalwart and Apache James).

WildDuck's API is much simpler, so when implementing something on top of WildDuck, you can only cherry-pick the specific features you need and ignore everything else. With JMAP, this is not really so. JMAP is a horror show – it's Lisp on JSON, like some kind of Frankenstein. The only value in JMAP is standardization. Who knows, maybe already in 20 years it really does replace IMAP and SMTP for the client.

Just look at that JMAP official API example:

[
    // First we do a query for the id of first 10 messages in the mailbox
    [ "Email/query", {
        "accountId": "u123456",
        "filter": {
            "inMailbox": "mailbox1"
        },
        "sort": [
            { "property": "receivedAt", "isAscending": false }
        ],
        "position": 0,
        "collapseThreads": true,
        "limit": 10,
        "calculateTotal": true
    }, "0" ],

    // Then we fetch the threadId of each of those messages
    [ "Email/get", {
        "accountId": "u123456",
        "#ids": {
            "name": "Email/query",
            "path": "/ids",
            "resultOf": "0"
        },
        "properties": [ "threadId" ]
    }, "1" ],

    // Next we get the emailIds of the messages in those threads
    [ "Thread/get", {
        "accountId": "u123456",
        "#ids": {
            "name": "Email/get",
            "path": "/list/*/threadId",
            "resultOf": "1"
        }
    }, "2" ],

    // Finally we get the data for all those emails
    [ "Email/get", {
        "accountId": "u123456",
        "#ids": {
            "name": "Thread/get",
            "path": "/list/*/emailIds",
            "resultOf": "2"
        },
        "properties": [ ... ]
    }, "3" ]
]

[alexanderadam]

JMAP is completely off the table for now.

People who're looking for a mail server with JMAP support might have a look at Stalwart mailserver (GitHub — they also support traditional IMAP) as mentioned by Andris.

Apart from being very resource efficient (it's written in :crab: Rust) and being security audited it also has many modern features (it even supports encryption at rest) and is easy to install.

PS: There's also a nice FOSS Android JMAP email client but Thunderbird doesn't seem to have support for JMAP yet.

[andris9]

Stalwart and WildDuck have different goals. WildDuck is designed for environments with tens or hundreds of thousands of active users and hundreds of terabytes of stored emails. And to achieve this, a lot of corners have been cut. Rust is a better option for these kinds of server applications, but the majority of the load for real-life usage is not coming from effective command handling (where Rust shines better than Node) but from fetching the emails from the backend storage.

To illustrate, below is a screenshot of a production WildDuck setup for deduplicated attachments.

[alexanderadam]

I believe you. I didn't claim that Wildduck and Stalwart have the same goals. :wink:

Some users just might not have "hundreds of thousands of active users and hundreds of terabytes of stored emails" and they just would be happy with a few hundred users who'd appreciate security features and maybe even JMAP (what this issue is about).

[andris9]

Yeah, in any case, Stalwart is a good option. On the WildDuck’s homepage I suggest using Dovecot+Postfix but by now Stalwart would probably be a better option.

[github-actions[bot]]

This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 15 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 15 days with no activity.