Show HN: WildDuck – Self-hosted modern email server

I don't run my mailserver on DO (I know a few people who do tho), but I've had few issues operating one on a no name host and another on OVH. If that was a persistent issue, it might be advisable to move to a host that isn't blacklisted.

My mail from DO doesn't get rejected, but ends up 100% of the time in spam.

Don't destroy your droplet then? Digital Ocean supports reinstalling VMs in place without destroying the VM. Floating IPs for a mailserver (esp. outbound) sounds a bit silly, mail infrastructure is more fault tolerant than other systems, to the point that a minute or two of downtime is far from the end of the world.

Furthermore, DigitalOcean silently drops all SMTP traffic on IPv6, which can be really confusing since you'll simply timeout and it isn't mentioned in the documentation. They do that because they implemented IPv6 against all standard industry practices (which were helpfully gathered in a RFC) and within hours of launching IPv6 the few /64s from which they were allocating customers /124s to landed on blacklists.

It's been 5 years since and they still have no plans to do IPv6 properly and allocate /64s [0].

This is the main reason I switched to Linode, who will happily allocate you a IPv6 range (/116, /64, /56) that can be rerouted between VPSes with a simple ticket (takes <1 hour).

[0]: https://ideas.digitalocean.com/ideas/DO-I-1366

Yeah, that is one workaround that is reasonable to use. I'm just a bit weird and want to do delivery to other servers without an intermediary :P

Using maildir (the current standard for mail storage) with any kind of remote file system is not the best environment to have. Maildir stores every email into a separate file and then uses rename() for every flag change. Marking 1000 messages as "Seen/Unseen" or adding a flag or moving to Trash means 1000 rename() calls in the file system. Multiply that with thousands of users also logged in to the system and doing their own things - you get many millions of inodes and rename()'s flying around all over. Good luck keeping a consistent copy or not crashing the mail server software as it waits for some queued rename() call over network FS to finish (and expects it to take nanoseconds as this is how long it takes in a local FS) while blocking everything else.

I shall reply to your comment and your parent comment in one go here:

I work on FastMail’s web interface, which is now based on JMAP. Here are my opinions on the matter.

What papaf says is flatly not true. What andris9 says is generally unreasonable.

At its core, the API part of JMAP is an RPC framework, with defined semantics for object synchronisation and querying. The most important part of it is those semantics, and they are necessarily more complex than what web developers are generally used to. Simple traditional-REST APIs or the likes of GraphQL lack those object synchronisation semantics altogether, and are wildly inferior for practical email clients. There is just no comparison at all.

There is more to JMAP than just the API calls, though. What I think is the most obviously important part is that it also defines a push mechanism, including the ability for email clients to be notified of changes; this is tied into the object synchronisation semantics with the ability to ask questions like “what changed between these two states?”—so that your email client (be it on the web or not) can be told “something changed in the emails” and efficiently fetch the delta and apply it to the user interface and any persistent storage you may use. This is something that the shown WildDuck API does not appear to support at all, and is in fact something entirely unsupportable on such a style of API. These things are hard to do properly, in a way that will give any semblance of performance or efficiency.

(It looks like WildDuck’s web interface does have some way arranged so that changes get pushed to the interface, but that doesn’t appear to be part of its public API, and I can’t imagine that it’s actually a good, flexible and efficient solution. I haven’t looked into how it is implemented at all, however. I’m open to discussion of what I’m confident will be its shortcomings, if you don’t like the aspersions I am casting.)

Now to return to papaf’s remark: JMAP’s method batching is not achievable with HTTP/2 or GraphQL; the key difference is backreferences, whereby you can establish data dependencies between method calls, so that you pass part of one method call as an argument to subsequent method calls. To pick a common example of something that the FastMail web interface does, this allows you to express in one HTTP request the following: “find the first ten emails in Inbox, collapsing threads (so that you get one message from each thread only); then, given those, get the threads that they are in; then, given those threads, get the basic details of the emails that are contained in those threads.” In the absence of backreferences, you would need probably three round trips, or a special case in the API that limits flexibility.

I will add that JMAP can be usefully combined with HTTP/2 so that you can issue multiple batches of requests simultaneously and use the results as they return.

Please read through all the content on the front page of https://jmap.io/. It provides good justification for why quite a few things are how they are.

Remember this most important fact: JMAP is an object synchronisation protocol.

You learn something new every day! Google translate didn't help me there :)