Do you think we should work on an open source solution for https://peps.mlstate.com ?
The project is a very clean webmail server, starting with our clean protocol implementations (SMTP, POP, IMAP) and does not require external projects.
Try with hn/hn...
Update: Please don't change the password for this hn account. As an admin, I can reset it, but have better things to do today ;)
I'm curious of the reasoning behind your decision to reimplement SMTP instead of just using Postfix, for example. I run mail servers for an ISP (and myself) and take advantage of a lot of the "advanced" functionality that Postfix has acquired in the last 15 years.
Our protocol implementations use a specific DSL, that generates Opa code which is strongly statically typed with high-level types such as variants/rows. Although we currently lack many features or optimizations, the approach is clean and much easier to certify.
Yes, we are thinking about the following business model for PEPS, which was built for an important account but of which we own the IP.
1. Open source under the AGPL license, so that anyone can host its own instance easily and hopefully we can build a community around the product. 2. Sell support (together with a non-AGPL license for corporations).
OR
1. Open source under the MIT license the current product. 2. Sell a complete packaged solution with add-ons for corporate users.
Any feedback between the two?
Please point out what exactly the different conclusions are to that text.
If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work."
That last part--"derivative work"--is somewhat the rub.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version
The definition of Corresponding Source code is listed earlier in this HN thread.
See, I can also use offensive language to describe a license. Doesn't that make for a nice conversation here on HN?
That said, as we need to make a living, and if we go the MIT way (see comments below), there are high chances that the Exchange support will be a paid extension.
Still, for people looking for a more complete package that looks like a much better alternative.
Not for me, because I'm trying to get away with a much smaller machine and less dependencies (i.e. I'm still really unsure if I want a webserver. I decided to go for clucene instead of solr because of the dependencies etc. etc.).
I will follow that repository though and think about recommending that to friends/coworkers though, depending on their needs/expectations.
https://github.com/darklajid/ansible-communication
Plus: While I self-host my mails for a while (without an automated setup of sorts, the one off snowflake sort of thing, so quite different from this here), I don't claim to be an expert here. Check what I did, take it as a template, don't use it without a basic understanding.
If there are some postfix/dovecot gurus out here and would like to point out obvious flaws in my setup - go ahead!
https://www.exratione.com/2012/05/a-mailserver-on-ubuntu-120...
I wouldn't do that again, though (hence my stumbling around with ansible). If the machine goes down/you want to recreate it or duplicate it for a friend's setup (without dd-ing everything and trying to figure out what to change later) you're back to square one. It's probably month or years after you read the guide that created your system, you don't have the link handy anymore, forgot all you learned about gotchas in the doc that were slightly different for your deployment.
These guides aren't bad per se. My current system is a heavily customized result of various "Here's how I do mails" guides as well and it works like a charm, for quite some time. But I could never reproduce it again, which caused my reluctance to jump from GMail as my primary account to the self-hosted one - even if that one works for me, for years.
IF all my critical data (password reset mails, banking information etc. etc.) end up on a host I'm responsible for, I want to be able to replace that thing ASAP if something goes wrong.
Currently (unfinished, see my link above), but:
time ansible-playbook -K -i hosts site.yml
real 6m29.708s
user 0m9.623s
sys 0m3.243s
That's from a bare bone installation (nothing on there but ssh, my unprivileged user with sudo privileges) to a running mail (smtp/imap), calender/contacts & xmpp server.
I don't claim that MY project is the way to go, quite frankly I'd be very uncomfortable to push others to use it. But I do believe that infrastructure that is this essential should be easy to recreate/reproduce, even for laymen/single persons.
There's also kolab.org which is completely free software (uses Roundcube for web interface since 3.1).
Also see: https://community.zarafa.com/
Achiles heel now for DIY solutions is the web mail. Roundcube, the best candidate, is not really stellar (almost unusable on 1366x768 screens).
I've been looking to get into it but just haven't made a move on it yet...
https://github.com/leucos/ansible-tuto
I'm actually not sure it's better than the shell scripts it replaced so I may end up switching back.
In general I hate the state of the documentation. It's barely usable.
I do like the simplicity of the format (.yml) and the architecture (no agent required, only dependency is python and I think even that can be bootstrapped via python).
My playbook (see above) certainly feels like a shell script packaged in .yml format, but .. I stumbled over and over again when I tried using ansible's modules (examples: No way to create postgresql roles without a password, no way to load data into postgresql => Two things I've to do via shell: or command: in my project).
Bottom line: I'm happy with the state I have, but I'm far from happy with ansible as a technology and probably wouldn't use it as it is for the next deployment project.
- jinja2 templating for config files - roles & tags - many error-cases already thought of and coded around.
That said: The point of these automated recipes is that you can run them _without_ reading a blog and copy/pasting things in a shell. I do plan to write about my experience. After I set up a blog. cough
What I'm lacking right now is a decent webmail client. Roundcube isn't exactly my type of thing, mailpile might be interesting. This seems ambitious and interesting in general, but seems to come with too much strings attached (puppet? No, ansible. Comes with postfix? I already have that). So .. it is more than I'd need.
I do like the idea of ready-made, easy mail server setups though (obviously, given the first paragraph). Perhaps a project like this could integrate well into owncloud or arkos though?