I think I’ve finally found my dream webmail client. It’s incredibly minimal and wonderfully extensible; I’m going to set it up for NixNet Mail, add a little bit of CSS, and recommend it over Roundcube.
I really hope not. Standard though it may be, HTML email is a cancer that needs to die out. I always recommend new users on my platform to read useplaintext.email.
Sanitized HTML e-mails are displayed in sandboxed <iframe> elements where many features are disabled (e.g. JavaScript). The Content-Security-Policy set by koushin is an additional security.
This can be easily disabled: just disable the viewhtml plugin
HTML is abused, but I don’t want email where I can’t even use bold or italic, or hyperlinks like the one you put in your comment. Why should emails be less expressive than forum comments?
(Yes, I would totally welcome Markdown email as a standard. I’m sure it won’t happen, though.)
Reverting to plain text, Markdown or some other kind of ad-hoc markup because HTML can be abused makes me shudder. I want nice typography and proper design in my emails. I want reading an email to be as good an experience as reading a well-designed website. In particular, I like the current resurgence of high-quality newsletters delivered to my inbox. Instead of throwing up our hands and giving up on this, I would like to see us actually attack and try to solve this problem.
A lot of good emails clients will display plaintext surrounded by underscores in italics and text surrounded by asterisks in bold. As to hyperlinks, that’s what [1]. Some clients that work particularly well with plaintext will make that [1] a clickable link so you don’t have to scroll down and search for it either.
I completely agree about markdown emails. The client that implements that will be my gold standard.
imagine if we had some well-specified plain text system for applying inline formatting to text that “good” email clients could render, and hyperlinks could go inline so you don’t have to use up more screen space and manually re-index them when you add or move them in the text.
maybe we could use less than and greater than characters to enclose the inline formatting commands. it would be great!
On a self-hosted instance, sure. There’s a doc for that . From what I can tell, if it was a public instance, you wouldn’t be able to use CardDAV or CalDAV for contacts and calendars.
I’m not sure if I’m missing it or if it’s not there, but there doesn’t seem to be any way to serve the web interface over https. Don’t see any “ToDo” items either: https://todo.sr.ht/~sircmpwn/koushin?search=https
It’s likely meant to be served from behind a webserver like NGINX or Apache with a reverse proxy; they would then handle TLS. That’s how I intend to run it.
[edit: found an Echo recipe and it looks like Koushin isn’t wired up to call StartAutoTLS]
Echo, the underlying web server says it supports “Automatic TLS via Let’s Encrypt”.
I’m screwing around with it inside my NAT’ed house network, so any Acme bits aren’t going to work….
This Echo recipe indicates that the server needs to be started via e.StartAutoTLS, but cmd/koushin/main.go starts it with e.Start, so it looks like it’s not supposed to be working at the moment.
Screenshots would be helpful :P
This project is being completed under a consulting contract with Migadu for their next-generation webmail. They’re also working on a theme:
https://sr.ht/mcvO.png https://sr.ht/ml1l.png https://sr.ht/Yk6A.png
If it’s not obvious yet from this, Amolith, and geocar’s comments: Koushin is themeable :)
Thanks, that looks a lot more promising than the other 2 posts.
I don’t have high standards and it doesn’t have to be beautiful, but unthemed without even half an hour of css work is a bit too little effort.
It looks really good! I like it. It reminds me of gmail, back in 2005, before it turned into a bloated piece of shit.
Here are some with the sourcehut theme included in the repo. https://up.lelux.site/npiqi6om.png https://up.lelux.site/veh8tkrj.png https://up.lelux.site/ywyoja28.png https://up.lelux.site/7pssytg7.png
https://i.imgur.com/ITdNwNA.png
https://i.imgur.com/6lCE3HD.png
I think I’ve finally found my dream webmail client. It’s incredibly minimal and wonderfully extensible; I’m going to set it up for NixNet Mail, add a little bit of CSS, and recommend it over Roundcube.
But will it support HTML email?
I really hope not. Standard though it may be, HTML email is a cancer that needs to die out. I always recommend new users on my platform to read useplaintext.email.
It does support HTML e-mails. However:
<iframe>elements where many features are disabled (e.g. JavaScript). TheContent-Security-Policyset by koushin is an additional security.viewhtmlpluginI’m curious about this sanitization. Is there a standard algorithm or set of checks that are performed?
Sanitization is performed via bluemonday, a widely used Go library.
HTML is abused, but I don’t want email where I can’t even use bold or italic, or hyperlinks like the one you put in your comment. Why should emails be less expressive than forum comments?
(Yes, I would totally welcome Markdown email as a standard. I’m sure it won’t happen, though.)
Reverting to plain text, Markdown or some other kind of ad-hoc markup because HTML can be abused makes me shudder. I want nice typography and proper design in my emails. I want reading an email to be as good an experience as reading a well-designed website. In particular, I like the current resurgence of high-quality newsletters delivered to my inbox. Instead of throwing up our hands and giving up on this, I would like to see us actually attack and try to solve this problem.
It’s funny, because that’s where Markdown comes from.
https://daringfireball.net/projects/markdown/syntax
A lot of good emails clients will display plaintext surrounded by underscores in italics and text surrounded by asterisks in bold. As to hyperlinks, that’s what [1]. Some clients that work particularly well with plaintext will make that [1] a clickable link so you don’t have to scroll down and search for it either.
I completely agree about markdown emails. The client that implements that will be my gold standard.
[1]: is for
imagine if we had some well-specified plain text system for applying inline formatting to text that “good” email clients could render, and hyperlinks could go inline so you don’t have to use up more screen space and manually re-index them when you add or move them in the text.
maybe we could use less than and greater than characters to enclose the inline formatting commands. it would be great!
Could I use it to read my Gmail emails?
On a self-hosted instance, sure. There’s a doc for that . From what I can tell, if it was a public instance, you wouldn’t be able to use CardDAV or CalDAV for contacts and calendars.
I’m not sure if I’m missing it or if it’s not there, but there doesn’t seem to be any way to serve the web interface over https. Don’t see any “ToDo” items either: https://todo.sr.ht/~sircmpwn/koushin?search=https
Am I looking right past it?
Yes, koushin assumes a reverse proxy is set up right now.
It’s likely meant to be served from behind a webserver like NGINX or Apache with a reverse proxy; they would then handle TLS. That’s how I intend to run it.
[edit: found an Echo recipe and it looks like Koushin isn’t wired up to call StartAutoTLS]
Echo, the underlying web server says it supports “Automatic TLS via Let’s Encrypt”.
I’m screwing around with it inside my NAT’ed house network, so any Acme bits aren’t going to work….This Echo recipe indicates that the server needs to be started via
e.StartAutoTLS, butcmd/koushin/main.gostarts it withe.Start, so it looks like it’s not supposed to be working at the moment.