We use server side spam filtering at c1 (see: https://c1.fi/about/). So far things are working pretty well but certainly false positives may occur. On the positive side client can contact yours truly and we can usually do something to sort these out.
Thanks fore commenting! The public informative parts of c1.fi are readable without JS. See https://c1.fi/about?lang=en for example.
Registering, account management etc. will require JS - Simply to provide better UX.
There are no 3rd party libraries or references (except on pages handling payments via Stripe) in use and the JS is not minified. No 3rd party trackers either.
Our self hosted email service, https://c1.fi, works fine with "plus addressing".
In addition I recently laid out plans for "disposable aliases" with a machine generated random string as local part for users in our shared domains (like c1to.me). So one could use an alias when signing-up with a service. Once the service is not relevant - Just delete the alias. All comments and suggestions are welcome. =)
> I ported the HelenOS kernel to RV64 in 2016, but I've never properly finished the user space support. I hope this board will be a good motivation for me to finally push the entire OS to the same level as x86-64
Support for client's own domain is currently under works. Our webmail supports PGP and one can use IMAPS/SMTPS or ActiveSync based native email clients too.
All servers self hosted (we run C1/Gentoo!) in our own computing facility in Finland. =)
C1.fi is a simple Finland based email service which supports using standard IMAP and ActiveSync clients. We encrypt all messages with account holder specific keys before storing them on servers mass storage. -- [email protected]
"By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript, passing in integer and floating point primitive data types. Thus, to access any Web API, WebAssembly needs to call out to JavaScript, which then makes the Web API call. Emscripten therefore creates the HTML and JavaScript glue code needed to achieve this."
Of course it is. In most cases you do not have any sort of guarantees regarding the browser (which it self usually is more complex piece of software than all your operating system and it's accessories calculated together - difficult to audit - known to collect metrics etc etc). In addition one can sandbox their local terminal pretty effectively - With Tomoyo or some other MAC technology. It's not so bad idea to actually isolate your browser too (with Mandatory Access Control) - It usually has no business for a global view on your filesystem or local network resources.
I personally don't appreciate the idea of using Rust as an overall "only solution" replacement. Requires LLVM (a huge overkill on a system otherwise based on GCC), no proper support for dynamic linking, own build system, absolutely huge "ecosystem", No standardization (-> no competing implementations), SLOW to compile... Yada-yada.
I think PGP is fine for encrypting some files. But you should take into consideration that when you encrypt a file it's very likely that some (or all) of the plain text is left behind on the block device. Using full disk encryption (LUKS for example) will give additional protection (so one can't read plain text fragments from the device when it's not "open").
* https://github.com/intc/c-notes/blob/master/threads/4-thrd_e...