Hacker News new | comments | ask | show | jobs | submit login

I just put the finishing touches on my ansible playbook for my 'Goodbye Google' server (Mail via dovecot/postfix w/ dkim, dspam, greylist, sieve, Radicale for CardDAV, CalDAV, Prosody for xmpp). Works fine so far.

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?

We have been working on such project in our own Opa technology for quite some time.

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 ;)

> starting with our clean protocol implementations (SMTP, POP, IMAP) and does not require external projects.

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.

The initial goal of the project was to have a total control on the TCB (Trusted Computing Base) of a webmail for high security environments, in order to be able to pass certifications such as Common Criteria (EAL).

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.

Mobile site needs some work.. But one suggestion is turn off autocomplete and autocapitalize for the username box... Makes logging in on iOS hard.

I'm getting an SSL error.

Yes, our certificate is self-signed for this demo. "Not to worry."

http://www.startssl.com/ No excuses its free :)

This is pretty cool. Will you do any kind of personal variant for gmail refugees?


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).


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?

AGPL would be perfect for such a product.

Voting for 2...AGPL is like biohazard level 4 viral.

And WTFPL which you are using is the level 5 of foul language, and the death sentence to software names.

See, I can also use offensive language to describe a license. Doesn't that make for a nice conversation here on HN?

To be fair, if you use our code under the WTFPL (and don't, because it's like three versions and two test suites out of date, at this point!) we don't require that you open-source any other part of your stack.

How exactly would it be viral in this case? I ask because it's damned confusing. Since this would be an email server, wouldn't it be a drop-in component in most folks' infrastructure? If I understand it correctly, it would just require me to make the source code of the email server/client itself available to my users...not any of my other unrelated infrastructure apps, correct?

This is the problem with the GPL/AGPL- what exactly must be open sourced under what conditions has been debated many times, and different people/groups have come to very different conclusions.

The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work.

Please point out what exactly the different conclusions are to that text.

I am not an expert on the various points of the debate- I only know it exists. You can Duck Duck Go for "gpl derivative work definition" and find some references to this debate. Perhaps someone else has a specific answer for your question, sorry.

Correct, just the source code of the AGPL application, not of your server.

I was under the impression that AGPL requires the open-sourcing of everything that touches user data at any point in the pipeline.

The AGPL is exactly the same as the GPL, except that if there is a button to click to download the source code of the program, you are not allowed to remove that button.

From the AGPL FAQ:

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.

If that part of the informal FAQ worries you that it might be interpreted in some strange way, just look at the actually license and read it.

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.

have you setup Exchange protocol support (for pushmail on iOS devices)? Gmail disabled Exchange protocol support for newer devices, that would be my main motivation to move away from Gmail.

Turns out we _do have_ an implementation of ActiveSync in Opa!

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.

This would simplify my life for sure.

Very nice interface. Kudos.

Thanks go to @tweetfr

Checkout https://github.com/al3x/sovereign , though xmpp hasn't been set up yet.

That looks awesome, thanks. You(?) went a lot further than me (and further than I want to go, admittedly).

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.

I have only contributed a little on the project, most of the work has been done by its main author and others.

I'm very suspicious when MySQL finds its way into an open-source package, due to its ties to Oracle. Why not Postgresql?

Why not MariaDB and then you don't have to worry about fixing third party packages that depend on MySQL specific behavior?

Why would an email client need an RDBMS backend in the first place other than the fact that, like WordPress, the devs did not value KIS? Squirrelmail does fine without a db, as do all of the command line clients.

Actually there's an issue open right now to switch to postgresql

I've similar setup on my server (except http://baikal-server.com/ for CardDAV/CalDAV and http://www.ejabberd.im/ for XMPP) and I was wondering if there is a simpler solution to email server for one person than postfix/dovecot/spam handling. I understand complexity of that subject but feels like there could be something that fits "personal server" scenario.

for a personal server, maybe try http://www.citadel.org/. One app that runs email, xmpp, calendar, contacts and notes, written in C++. I've installed just on one machine. The interface is awful, but the rest seems to work pretty well.

Care to make that playbook publicly available? I would also be interested to try out hosting my own email, but am somehow afraid of setting it up wrong.

Just pushed my current status to

Careful though: This isn't deployed outside of test machines yet. I'm still working on the proper backup/restore scenarios, consider a couple improvements etc. - the readme outlines what I would like to do next.

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!

Here is the dovecot documentation for your "auto-create imap folders" issue: http://wiki2.dovecot.org/MailboxSettings

This guide works like a charm, takes about 2-3 hours to setup:


I'm pretty sure I followed one of those previously.

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
(Most of the time is spent in downloading packages/installing them: Got a faster network? This will be faster as well)

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.

Have a look at Zarafa (http://www.zarafa.com/). It's free and open source, although Outlook integration is a paid option (via a plug-in). Comes with a modern webapp (http://www.zarafa.com/content/webapp).

And also...Zimbra (http://www.zimbra.com). This is what I've used to replace gmail for now, and aside from some quirks, it's working well.

Zimbra is pretty damn nice. A bit resource hungry, but very functional.

> It's free and open source, although

There's also kolab.org which is completely free software (uses Roundcube for web interface since 3.1).

Zarafa is awesome! Is that a custom web-app? It resembles Outlook; just want to confirm that its actually not.

As an ex-zarafa employee I can confirm it is written in-house, from scratch. Uses Extjs.

Also see: https://community.zarafa.com/

It's a custom webapp that's modeled after Outlook, hence the resemblance. Try the demo, I'm sure you'll like it ;)

Outlook integration is a paid option, but z-push (ActiveSync implementation) is free.

http://www.sogo.nu/downloads/zeg.html sounds interesting too.

Hello, I'm working on a similar thing based on mailboy[1], you might be interested in the admin interface.

Achiles heel now for DIY solutions is the web mail. Roundcube, the best candidate, is not really stellar (almost unusable on 1366x768 screens).

[1] - http://manurevah.com/blah/en/p/mailboy

mailbox looks suspiciously like postfixadmin, is it a fork?

Do you have a blog post of everything you've installed and getting them all to work well together? I've been interested in creating my own "Goodbye Google" server, but never get started:(

Not yet, but that _is_ planned.

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

Sort of related: how'd you get started with Ansible? Did you just dive in and hack around or follow some sort of guide or tutorial?

I've been looking to get into it but just haven't made a move on it yet...

I've started using it over the last month. The docs on the web site are good and this hands-on tutorial was also helpful:


I'm actually not sure it's better than the shell scripts it replaced so I may end up switching back.

I've to disagree about the state of the ansible documentation, I guess. As far as I understand the website was restructured not too long ago and a lot of stuff is .. broken. I fell back to using the Google Site Search thingy to find anything, because ansible's documentation lacks any kind of index/reference (except for the modules page, which is nice). There's a good deal of magic involved, and passages in the documentation even state stuff like 'there are a couple of these magic variables, but not too much' (Note: No list is provided).

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.

The things I really like about ansible compared to shell scripts is:

- jinja2 templating for config files - roles & tags - many error-cases already thought of and coded around.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact