Live data from Hacker News

JMAP for Calendars, Contacts and Files Now in Stalwart

stalw.art

141–150 of 204 posts

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#141

Reading weirdly many “but there are no clients” posts. Of course something has to come first. You can’t really develop a client without a server implementation and Stalwart is essentially the first server implementation of JMAP. With Stalwart in place, there’s finally a reason to develop a client for JMAP. I hope y’all are aware that Mozilla’s new mail service will use it, so that is likely going to give JMAP a big p…

Stalwart isn't the first implementation of JMAP.

It's the first implementation of JMAP applied to stuff other than Mail.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#142
post #15

Running Stalwart in production for ~20 heavily used accounts for some company and no problems so far! The simplicity for such a complex stack and flexibility of deployments is off the charts!

Can you share what's your solution for filtering incoming spam? I've had to abandon Stalwart because its spam filter is so ineffective and inconsistent.

Mind you I am hosting this just for about a week now - +100GB in total for all inboxes. Also I removed automatic daily purging so all spam and deleted items stay just to be safe.

Haven't looked into spam more closely yet. After first glance on most publicly shared email address - there is around 2 spam messages per hour.

Here is report prepared by llm which looked through the last 20 email headers found in spam. All of them were categorized correctly, however there were few emails in the past few days which went to spam where they shouldn't but I think this is fixable.

- Critical Authentication Failures: A large number of the messages failed basic email authentication. We see many instances of SPF_FAIL and VIOLATED_DIRECT_SPF, meaning the sending IP address was not authorized to send emails for that domain. This is a major red flag for spoofing.

- Poor Sender IP Reputation: Many senders were listed on well-known Real-time Blackhole Lists (RBLs). Rules like RBL_SPAMCOP, RBL_MAILSPIKE_VERYBAD, and RBL_VIRUSFREE_BOTNET indicate the sending IPs are known sources of spam or are part of botnets.

- Suspicious Content and Links: The spam filter identified content patterns statistically similar to known spam (BAYES_SPAM) and found links to malicious websites (ABUSE_SURBL, PHISHING).

- Fundamental Technical Misconfigurations: Many sending servers had no Reverse DNS (RDNS_NONE), a common trait of compromised machines used for spam.

There have been few messages which went to spam which didn't meet any of this spam criteria but actually they were cold marketing emails, so it's good too. In addition to this stalwart emits info log for each possible spam message ingested. Not sure if this can get any better than this.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#144
post #6

While JMAP seems to scratch every itch of a sucker for proper web API design, I’m wondering if the design space for new protocols should really be constrained to layers on top of HTTP. Is there really any new-ish binary protocol these days? Stuff like file sharing or groupware, mail, calendars, and so on—these things could be a lot more efficient and don’t really need the overhead of JSON as the message interchange f…

> I’m wondering if the design space for new protocols should really be constrained to layers on top of HTTP. Absolutely yes, IMO. This significantly eases web client development.

Not being tied to well-known port numbers, and by extension a single service per IP address, is also great.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#145

Earlier quoted context omitted.

Gilded tower? Are we living in separate universes? Shameless plug for a client with true offline-first IMAP support: https://marcoapp.io

Sounds like it :) I’ve been very happy with Mail.app since MacOS 10.0. My use has always been with my employer’s IMAP servers, and my own cryus (and eventually) dovecot self-hosted IMAP servers. Mail.app is what NeXT used internally, and Apple uses to this day AFAIK. Steve Jobs historically paid a lot of attention to it and wasn’t shy about weighing in on any changes. Most of the complaints that I’ve heard about it s…

Well Jobs is long gone. Apple Mail seems like it hasn't been touched much since his days.

I've written about my experience and motivations here:

https://marcoapp.io/blog/marco-an-introduction

Gmail does indeed _intentionally_ provide poor IMAP service. But the long and short of it is that Apple Mail simply isn't a first-class product. It's an afterthought.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#146
post #115

Stalwart is, from what I’ve read, an excellent JMAP server. JMAP is, from what I’ve read, a great protocol for building an E-Mail (and now also others) client on top of. Since I would like an innovative way to access my E-Mails, but do not want to self-host, I would find it interesting to use Stalwart as the server component of an E-Mail client : Data is somehow synced into Stalwart via the “ugly” protocols and I get…

This should be pretty straightforward to do with an IMAP IMAP syncing tool, like mbsync [1]. You'd run it periodically in the background to sync the remote IMAP to Stalwart's local IMAP server, and Stalwart can then automatically serve that via JMAP, doing the translation internally. I was originally thinking you'd need to go remote IMAP maildir Stalwart IMAP, which would be really complicated, but I think the IMAP I…

imapgoose which was recently featured here I think is another option: https://whynothugo.nl/journal/2025/10/15/introducing-imapgoo...

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#147
post #65

Earlier quoted context omitted.

Is there a reason you use aws s3 vs the hetzner object storage?

I heard some second-hand accounts that Hetzner's object storage was pretty slow even in the same location. For email, that sounded not too ideal. Also, I only have 5 mailboxes right now holding less than 15GB of data total... S3 is still cheaper than the minimum at Hetzner since I don't need anything close to a TB.

Good to know, I thought about using this with stalwart, as I moving to hetzner.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#148

Earlier quoted context omitted.

> Notoriously so, it's why MIME types and MIME encodings get so complicated. I made up ULFI because I thought MIME has some problems. > JSON may not look efficient Efficiency is not the only issue; there is also the consideration of e.g. what data types you want to use. JSON does not have a proper integer type, does not have a proper binary data type (you must encode it as hex or base64 instead), and is limited about…

> JSON does not have a proper integer type What are the drawbacks to using the JavaScript Number (really a double float I think) datatype as an integer in an object representation language such as JSON? I've never seen a use case where e.g. 42 (int) could be confused with 42.0 (float). If your application needs specifically an int or a float, then the ingesting application knows that. If the answer is monetary values…

Even if we assume that JSON numbers are JavaScript numbers. There is the problem that some large natural numbers cannot be represented in double or float although some even larger numbers can be represented. This is very bad if you use these numbers as IDs.

    scala> (Long.MaxValue-1)
    val res4: Long = 9223372036854775806
                                                                                
    scala> (Long.MaxValue-1).toDouble.toLong
    val res5: Long = 9223372036854775807
The fact that I used Scala is irrelevant here. That is true for many programming languages that 64 bit long and double types.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#149
post #41

Earlier quoted context omitted.

Where is the overhead in a container? It is just a regular process. (Ok plus a container runtime process, but that is negligible)

Does podman have a container runtime process? Or does it just exec the child after setting up the environment? In that case the overhead is just a small amount of kernel accounting.

It's the latter - podman just sets up all the necessary stuff - namespaces, cgroups, seccomp, network, mounts, etc - and then executes the child. No monitoring whatsoever. The best you can do is to have it listen on the socket it uses for the control API (similar to the docker socket).

However, the quadlets technology allows you to easily setup systemd using systemd generators to initialize the containerized applications using podman and then monitor it for any crashes. Quadlets essentially does everything that docker compose does.

That aside, a container's main overheads aren't the compute or the memory. It's the storage overhead. You're essentially replicating the minimal Linux userland for each container, unless that's in a shared layer.

Post reply on HN