Data Footprint Control -- Your own email server!

Lately I've been talking up the idea of "data footprint".  It's a fact that we're spreading all kinds of personal data around the Internet in the course of our modern electronic and financial lives.   Our bank, Facebook, Google, Yahoo, Comcast and essentially everyone we do business with is collecting data about us. The data get bought and sold and snooped no matter what our wishes may be.

One concrete thing I could do, while having a bit of fun, was to move my Google email back to a server computer under my own control.  That's (a) a rather old-fashioned thing to do, (b) rather complicated to set up correctly, and (c) a losing game in terms of functionality.  No doubt Google Mail sets the standard for usability, especially for power users.  It also has the best anti-spam technology I've come across.  So if we step back to a local server, we will be losing some useful features.

It happens I have an older Raspberry Pi (256 MB Model B) which hasn't had a particular mission.  So now it is the household IMAP server, with my 1.6 GB email stash on a 16 GB SD card.  It would have been easier to use a big PC for this function, but I wanted a platform that I could leave on 24/7 without eco-guilt.  It uses just a couple of watts of power.

I am temporarily (until I forget all the details) an expert on Postfix, Dovecot, and SSH, allowing me to access the e-mail from any machine on the home network and (securely) from external machines. Fortunately, I have an external SMTP relay that is part of my web hosting service, so outgoing e-mail should be treated with proper respect by the big services.  (A user PC directly sending out SMTP mail is often shunned as a likely source of spam.)

It's a just a symbolic step. We have a long way to go before we get control of all our data.

UPDATE 1: The dirty little secret they don't tell you at e-mail school is that most e-mail is spam, and an e-mail server without spam filtering is ... not worth a lot.  On the client side, Thunderbird and some others make a valiant attempt, but it wasn't going to work for me.  Especially since I want to use an Android client like Kaitin (no spam filtering) for mobile e-mailing.  So I consulted  https://help.ubuntu.com/community/PostfixAmavisNew. (Ubuntu is close enough to Raspian.) Everything installed OK until it became clear that my 256 MB Pi might not support a big freshclam update.  OK, we don't need antivirus for Linux/Android, do we?  Anyway, the server has started bouncing spam pretty well now.  And the Pi can feel virtuous as it crunches on each message for a second or two.

UPDATE 2:  ClamAV is hopeless, taking way too much RAM and CPU.  Fortunately Amavis doesn't need antivirus, so it's OK just to remove it from the system.  Even so, Amavis & co. take a lot of RAM and just fit in the 256 MB machine along with Linux.  If I start doing package updates, for example, there is a lot of "disk" thrashing -- swap utilization climbs, and things go very slow for a while.  (But no crashes!) A 512 MB machine would be much better.  Spam scanning and message handling seem to take 5 to 15 seconds per message.  This is not a high volume solution, but it handles my load OK.

UPDATE 3: This project was a success technically, but Comcast woke up to it (maybe they read my blog?) and they blocked port 25 on my service. Maybe I could have argued my case, but I didn't pursue it. Instead, I moved my email action to Pobox.com, a commercial outfit that specializes in email - and doesn't sell my info to the highest bidder, hopefully.

ARRL Handbook: Cool, but Heavy Reading

Yesterday, I got my engraved hardbound copy of the 2014 (Centennial) Handbook.  It's the Ham Bible, they say, but it's big!

In fact, it weighs in over 6 lbs (2.7 kg). This makes it rather difficult for reading in bed, especially for us geezer types.  (Note for reflection: the actual Bible, as usually printed, is much more user-friendly!)

My solution: upload the CD right away to Google Drive.  (privately) That makes it available wherever I'm likely to be.  And with the Nexus 7, it's quite manageable while reclining!

So apart from the cool-factor of having this tome on my bookshelf, it would be just as well to get my Handbook via Google Drive directly -- or some other network based solution.

(We might ask what it would be like if each chapter of the Handbook had an accompanying online wiki where readers could add their material.  Mixing curated and non-curated content would be a challenge, but a worthy one!)

At right is the classic ARRL graphic (ca 1975) that I seem to carry around in my head.  A very nice portrayal of the then-modern ham!

And strangely enough, it must be one reason while I frequently go up to HQ, and why I'm thinking about the Second Century Campaign.

Station Computer Upgrade

I had enough!  My creaky Intel Atom-based computer had enough oomph with Ubuntu to run fldigi, but just barely.  It couldn't handle a browser and logging program running alongside very well. So the D945GCLF motherboard supporting an Atom 230 processor and 1 GB of RAM is now surplus. (See right.) Note that it has on-board serial and parallel I/O ports - a rarity now! (I originally chose the Atom board as an experiment to see how small a processor was really necessary. I answered that question.)

Upgrading was straightforward.  I could keep the power supply, case, DVD drive, etc.  The board is an MSI B75MA-P45, which will run many current Intel chips.  (Left) I selected the "Celeron" G1610 (2.6 GHz, 2 cores) to run with a "mere" 2 GB of RAM.  Choosing the configuration was helped quite a bit by Ars Technica's "Bargain Box" System Guide. My logic was that any new system, even a "bargain" system, would be way better than what I had been using.  And that has proven correct.

The hardware change went smoothly enough.  The real work (no surprise) was building the new Ubuntu environment with needed development tools and Amateur Radio applications. It will be some weeks before we get all the way back to equilibrium.

Added: I ran the BOINC Whetstone and Dhrystone benchmarks on the G1610 and then on my "big" i7-920 machine.  For 2 cores, the G1610 gives 2768 floating point and 16928 integer MIPS per core. For 2 cores (of 4), the i7-920 delivers 2869 floating and 16577 integer per core.  So core for core, today's "budget" CPU is comparable to a premium chip of a few years ago.  Such is Moore's Law. The '920 will run 8 independent execution threads across 4 cores, giving it 2-4 times more potential in terms of throughput. In practice, that throughput is only realized when I'm cranking 8 threads of BOINC apps, which is a nice thing to do, if your tastes run to extraterrestrial intelligence, pulsars, or gravity waves.

Purists will note that Whetstone and Dhrystone aren't great benchmarks, and I'd have to agree. All I will say is, they came easily to hand, and they're better than BogoMIPS.