Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JMAP for Calendars, Contacts and Files Now in Stalwart

stalw.art

Post reply on HN
Print view View original

181–190 of 204 posts

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

#181

Post by Avamander »

blacklion wrote: post #167
Avamander wrote: post #108

Earlier quoted context omitted.

Solved problem? Dovecot can't handle UTF-8 to this day. Things like Stalwart do try and change that and actually support non-legacy features. (Though I think Stalwart doesn't do IMAP NOTIFY either.) Clients on the other hand have actually kinda moved forward, Apple Mail works with IMAP servers and offers features that people only got with Gmail before. But there are many other examples as well.

What do you mean, dovecot can't handle UTF-8? It works with any properly MIME-encoded message on one hand and allows (even requires) proper UTF-8 for folder and namespace names on the other hand. I don't have any problems to use UTF-8 in my messages received via dovecot and I have some folders with national characters on my account, and it works both with IMAP and Sieve.

No proper SMTPUTF8 support for starters.

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

#182

Post by brongondwana »

Loic wrote: post #128
brongondwana wrote: post #125

Earlier quoted context omitted.

We're working on it. We still use an unholy set of earlier versions of JMAP internally for our contacts and calendars; in particular the caldav_sync code is gnarly - I wrote it over 10 years ago when I knew less about calendars than I do now! It's still using an earlier branch of what became the perl Net::CalDAVTalk library interally, even though our frontend API is an almost-up-to-date version of what will become th…

Off-Topic: Thank you for not only providing a stellar service with Fastmail, but also for contributing back to the OSS ecosystem and the specifications/RFC work. This takes a lot of time and we all benefit from this work. It helps many people/small IT shops to run a system outside of the "big ones". Again, thank you.

You're welcome! We're all very keen on keeping email open and something that everybody can build their own tools for.

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

#183

Post by gtech1 »

sylens wrote: post #21

We need better client support for JMAP. Apple Mail, Thunderbird, Outlook (as if), and so on. I'm surprised some of the smaller ones like Canary or Spark don't implement it as a product differentiator.

Outlook ? Lol. In 2 years-time Outlook will only connect to MS365 and that's it. You're betting MS will switch to JMAP ? Lol again.

P.S. ("New" Outlook already only connects to MS365 servers and then stores your credentials and data on Azure, while they proxy to your actual IMAP/SMTP server )

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

#184

Post by afiori »

jeroenhd wrote: post #132
WorldMaker wrote: post #118

Earlier quoted context omitted.

HTTP/3 replaces parts of OSI layer 4 (TCP/UDP). There's a perspective that HTTP has been trying to lower its layer for decades. Especially the way that TLS originated as HTTPS but now is almost a "universal" vertical chunk of Layers 4, 5, and 6. In that perspective HTTP is probably the new Layer 6.

HTTP/3 uses QUIC as a layer 4 equivalent (which is actually just UDP with extra implications in practice). Not many services leverage standards-compliant QUIC other than HTTP/3, but you don't need to do HTTP to get the same protocol working. If anything, HTTP/3 running on top of QUIC forced shitty middlebox vendors to de-ossify by permitting any QUIC-based protocol, as they cannot practically distinguish a new HTTP/3…

My understanding is that they cannot even really recognise a QUIC connection (maybe the first time, but not after ip roaming)

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

#185

Post by zzo38computer »

afiori wrote: post #175
zzo38computer wrote: post #67

Earlier quoted context omitted.

> I’m wondering if the design space for new protocols should really be constrained to layers on top of HTTP It shouldn't. For some cases it helps, but other times it doesn't. Sometimes it helps but there would be better ways to do it, making it on a simpler protocol or making an entirely new protocol (which might or might not use TCP; sometimes it is better to use TCP and sometimes not) depending on the specific case…

Is der the same as ASN.1?

DER is one of the formats of ASN.1 (in my opinion it is the only good one).

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

#187

Post by afiori »

RedShift1 wrote: post #114
dotancohen wrote: post #78

Earlier quoted context omitted.

> 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…

Much easier would just be native decimal support in JS and we can represent a decimal using d as the decimal point, for example 15d0 (15.0) or 384d25 (384.25). Using cents instead of dollars sounds fine until you have to do math like VAT, you really need decimal math for that.

Many applications simply use strings for that, like for dates

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

#188

Post by yyyk »

Gormo wrote: post #163
yyyk wrote: post #25

I can understand why JMAP instead of IMAP given the latter's antiquated design. I don't see the advantage to clients in replacing WebDAV though, and the others are a bit iffy too. They'll need to make a way better sales pitch than 'JSON vs XML' (serialization ain't tough, XML is supported everywhere). I guess contacts/calendar follows JMAP naturally when the clients already implement it, but that only applies in the…

> I can understand why JMAP instead of IMAP given the latter's antiquated design. I think we're about ten years past the point where "newer = better" was a reasonable starting presumption.

If "newer = better" was my thinking, I'd be all for these new protocols on top of JMAP. But I actually think they're useful only in a limited context.

JMAP is better than IMAP because IMAP is a too stateful design, the IMAP/SMTP distinction allows for misconfigurations where sending doesn't work, has dozens of extensions where key extensions are inconsistently supported, doesn't have as many batched operations, etc. One could make an effort to improve IMAP - but the effort to do this consistently in server software would likely be comparable to adding JMAP and the result worse...

OTOH, the new protocols intrude on areas that go far beyond email software (you're very unlikely to get support for these in older Androids/iOS/Windows even if the modern OSs ever consider them), and don't offer as much as JMAP offers over IMAP. The cost/benefit is worse. They may make sense for a JMAP email client but IMHO not elsewhere.

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

#189

Post by bruce343434 »

audelair wrote: post #171
bruce343434 wrote: post #157

I tried to set up stalwart, but I didn't understand exactly what it wanted me to do. It's a webserver (for webmail and admin) and mail server in one, but I already run a webserver and I already have cert infra. So I couldn't figure out what dns settings to use and what ports to reverse proxy. And how to get it to play nice and share the certificate. Seems like stalwart has been designed as if it is the only thing run…

I have had similarly been unable to get as much help from their Discord as I had hoped. That said, I'd give this another shot. What I discovered is that Stalwart is incredibly flexible and designed to be used in any configuration you want, and the documentation and examples are incredible, compared to most other projects. BTW, there is no webmail yet, but you are right that there is the admin that is served over HTTP…

Did you use the documentation to figure out the proxying? I can't see a clear path of how to reconcile giving the responsibility of certs to another software, but still having stalwart use them for imap and smtp tls. And do you have the stalwart web interface running on www.yourdomain, or did you manage to get it working on a different subdomain? I don't see the config syntax in the docs for changing that

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

#190

Post by audelair »

bruce343434 wrote: post #189
audelair wrote: post #171

Earlier quoted context omitted.

I have had similarly been unable to get as much help from their Discord as I had hoped. That said, I'd give this another shot. What I discovered is that Stalwart is incredibly flexible and designed to be used in any configuration you want, and the documentation and examples are incredible, compared to most other projects. BTW, there is no webmail yet, but you are right that there is the admin that is served over HTTP…

Did you use the documentation to figure out the proxying? I can't see a clear path of how to reconcile giving the responsibility of certs to another software, but still having stalwart use them for imap and smtp tls. And do you have the stalwart web interface running on www.yourdomain, or did you manage to get it working on a different subdomain? I don't see the config syntax in the docs for changing that

The documentation needs a lot of work, especially since a lot of it is outdated. But in short, if you setup a reverse proxy, the listeners in Stalwart will listen to anything forwarded to it, so you'll generally want to refer to the HTTP endpoints to map it to the right subdomain. https://stalw.art/docs/http/overview

For instance, you can simply point something like mailadmin.domain.com to Stalwart on port 8080 and it'll just work. In this case, whatever your mail server's host name (i.e. mail.domain.com or whatever) wouldn't really matter.

But then your reverse proxy can handle the other endpoints like /dav/, /.well-known/ on a different subdomain. And mta_sts.domain.com directly handling /.well-known/mta-sts.txt for instance.

For my stack, outside of Caddy's https handling, I kept things simple and exposed 25, 465, 587, 993, and 4190 (smtp, smtps, imaps, and ManageSieve) TCP services binded directly to the host.

Using Caddy's certificates is also documented at the end here: https://stalw.art/docs/server/reverse-proxy/caddy

But it leaves it to you to map things. For instance, if both Caddy and Stalwart are containerized, it's easy to get mixed up on where the bind-mounted or named volumes (depending on how you set it up) will end up placing them. But it does work... just so flexible that it's out-of-scope for Stalwart to document everything.

Post reply on HN