It looks like a good idea to self host a mail server (for me, for my familiy): it's a way of communicate that I really love, supports encryption, and if the server is down, delivery will be retried for several times (even days!). It can be done in a complete free as in freedom software stack.

Email scales beautifully without anybody at the center keeping all of it. We need to make a mail server for people that costs five bucks and sits on the kitchen counter where the telephone answering machine used to be, and that s the end of it. If it breaks you throw it away. ("Snowden and the Future, Part IV: Freedom's Future" by Eben Moglen ) (edited to add a closing parenthesis so I don't go mad)

Eben Moglen says "we need to make" so that means that we are not there yet. Spam fighting, other servers mark your mails as spam, people not remembering your email address, difficult to maintain... Many fears that I would like somebody to tell me that they are only #FUD, but I'm afraid is not so easy as setting up a Wordpress (wink to Mike Linksvayer) or even a Mediagoblin (wink to Christopher Allan Webber). Some of my heroes here, jpope and sazius, host almost their everything but not their email. Many free software communities offer email alias to their full-qualified members, I wonder why an email alias and not an email account, given that it's a so basic need (even Universities offer that to their students) and the communication of the project is based on that in many cases too. Maybe legal reasons?

So, I'm going to try to read a bit about this topic, and maybe do some test installs of mail server. From this lovely pump community, what I would like is:

• Practical experiences (for example, if you run your own mail server, hardware and other kind of needs, the software stack that you use, the good and the bad things).
• Thoughts on that paragraph by Eben Moglen. If agree with it, and if you know projects that are working on that.
• Any other comments that you like :)

This is cross-posted from my blog

I have added a package for pump.io to the AUR: link. Hopefully, if someone attempts to use it, it actually works.

At the time of this writing, I've been using Arch for about 2 years. During this time, I've downloaded and edited PKGBUILD's from the AUR quite a few times. Until recently, I haven't actually maintained any public PKGBUILD's. Time for that to change.

I wrote the PKGBUILD from scratch, using a few others as a guide, along with the Arch wiki entry and my pump.io setup.

Installing pump.io from the AUR will install it to /usr/share/webapps/pumpio, place a sample config file at /etc/webapps/pumpio/pump.io.json and a systemd file at /usr/lib/systemd/system/pumpio.service. The AUR package will install the node dependecies (along with databank-mongodb and databank-redis as they seem to be the most popular databank backends currently). With the sample config that is installed, you should be able to run a testing pump.io instance as soon as it's installed.

Here would be me installing it and running it. Adjust commands as needed:

$ cd ~/aur
$ cower -d pumpio-git
$ makepkg -i
$ su -c 'systemctl start pumpio'

Then, open http://localhost:8000 in your preferred browser. (so long as it isn't IE (oh, wait. Us Arch users are smarter than that...)) Create an account and have fun pumping.

Notes concerning the package:

• This package creates a new user pumpio, so long as it doesn't exist
• The systemd service runs
  /usr/bin/node ./bin/pump -c /etc/webapps/pumpio pump.io.json start
  to start the pump using the pumpio user
• If the pump process dies for any reason, systemd will attempt to restart it
• The sample config is set to use the memory databank which is perfect for testing. Your data will be wiped (aside from uploads) when you stop/restart the process
• The pump.io logging option is enabled however, no logfile is set. This allows for the logging to go straight to the system log. Run # journalctl -f -u pumpio to see live logging.
• Photo uploads are set to go to /tmp/pump.io/uploads via the sample config
• There is likely something else that I should put here but, I'll just have to add it in later...

If you decide to run a pump in production, you'll not want to use the memory databank. Choose a proper databank. You should be able to install the databank globally (i.e. npm install -g databank-****) and it'll work. Also, don't forget to install your preferred datastore via the repos or AUR and get it up and running. You'll also need a permanent uploads directory and set it in the config. To set any other config options, check the wiki and config options for more. Also, you may want to see my pump.io blog post, then again, maybe not...

If there are any issues with the PKGBUILD, please let me know either via the AUR or my contact page . Considering that this is my first "proper"0 package, it's bound to have issues.

Sidenote: Also, I am using cower my usual yaourt thanks to Andrea Scarpino's suggestion. Seems nice so far, not nearly as automated as yaourt but, that's actually a good thing.

Hmmm.. I don't know...

For me, the sign that I'm at the right friend's house, would probably be that their WiFi is an Ethernet cable =)

Pump.io wins the Internet!! :p

Dammit. I'm a whistleblower with no whistle or puff and also no secrets, but I demand my anonymity!