Tag Archives: email

Posted on
by

I am not a big fan of Facebook’s Pavlovification of life, and I try and spend as little time as possible on it. This, unfortunately, has lead to me missing invites to things.

I was shooting the shit with a mate of mine recently, who is even more anti-Facebook, and here’s what I came up with.

iCal Feeds

One of the hidden features Facebook has is that it’s feed of events you’re going to or have been invited to, is made available via an iCal feed you can subscribe to. I had already added this to my Google calendar (add another calendar by URL), so I get a list of upcoming events appearing in my calendar, and you can even tell Google calendar to send you a notification email when new stuff is added.

However, Google has its own problems, so I thought it’d be nice to get a weekly email digest of upcoming things.

Python lists

So, using the python-icalendar module, I wrote a very quick bit of python program that you an point at an ical feed, and get a summary list of upcoming events printed to the console in a nice list. It uses the summary text of the event, together with the start and end times, and, if available, the location and URL link (handy for Facebook events).

It automatically removes events that have already ended, and by default only lists events that start within the next 7 days.

Use it as follows:

python parse_cal.py -u 'https://url.of.feed/ical' -d *numberofdays*

Which outputs something like:

 * Church Of The Heavy presents ECHO4FOUR...VIOLENCE IS GOLDEN...NO DICE GRANDMA...INFURIOUS
     2016-02-24 19:30 - 2016-02-24 22:30
     Wheatsheaf Oxford
     http://www.facebook.com/events/468321193354736/
 * THE HIP DROP!
     2016-02-25 20:00 - 2016-02-26 01:00
     The Bullingdon  (Oxford)
     http://www.facebook.com/events/141392559560311/

Which are two awesome events I’m heading to in the next few weeks (two very different styles of music!)

Now the email

Getting a weekly digest then is just a matter of a bit of cron and mailer goodness, edit your crontab thus:

@weekly /usr/bin/python /path/to/parse_cal.py -u 'https://feed.example.com/calendar.ics' -d 7 | mail -E -s "This week's upcoming events" you@example.com

The program only outputs something if it finds things, so the -E tells mailx to not send anything if there’s no message body.

And you’re done!

I’ve found this pretty handy for a few other calendar feeds (my work joblist for example). Enjoy!

» Visit the project on Github...

Posted on
by

So, following on from the theme of other week’s post, this is a very quick plugin which will opportunistically encrypt email sent by Known.

It works in much the same way as the similar WordPress code; if a key for a user is in the keyring, the email is encrypted before it is sent. It is particularly handy when combined with my PGP Signin code, since that will provide key discovery.

I wrote this for my own use, so it’s not perfect. For example, since Known sends all email as HTML (unless my plain text email patch is also applied this patch was merged into core), my plugin currently just strips tags, which at least makes the email somewhat readable.

Anyway, kick it around.

» Visit the project on Github...

Posted on
by

We all know how important it is to secure web servers with encryption. As I’ve mentioned before, port 80 HTTP should be considered deprecated at this point!

Just as important (potentially more so), but often overlooked, is to ensure that your email server is also secure.

STARTTLS is a technology that lets you start an encrypted session during a standard SMTP connection. In the same way as HTTPS secures web, STARTTLS will secure email in transit from your mail client to the server, and from server to server. This makes it much harder to passively read the traffic, and having more encrypted traffic on the internet is only ever a good thing.

This only protects email in transit from server to server of course, so this is not a replacement for end to end encryption methods like PGP, but it does complement it… and since most email is still sent insecurely, this adds extra security without requiring your users do any extra work.

It’s easy to set up (for Exim at least), and it transparently runs on port 25, so there’s no reason not to!

Generate your keys

As with web, you’ll need a server key and certificate file.

For my public mail and MX relay servers, I decided to use valid certificate authority certificates. Clients, and some relaying servers, will throw a certificate error for self signed certificates, but others will not. Better safe than sorry, and since I already had a valid certificate on my site for the server in question, I simply recycled the certificate.

If this is your internal server, you can use a certificate signed by your own certificate authority, supported by the machines in your organisation.

The default exim configuration expects to find certificates in /etc/exim4/exim.key and /etc/exim4/exim.crt.

Enable TLS

The basic STARTTLS configuration by simply editing exim4.conf.template and setting MAIN_TLS_ENABLE = yes in the tlsoptions section. Restart exim and you should have STARTTLS support enabled.

As with a web server, you can configure ciphers etc at this stage. On my server at least, the defaults seemed reasonably strong, but as we learn which ciphers have been compromised by GCHQ and the NSA, we might need to tweak these.

Test your configuration

Next, you should test your configuration.

To do this, the simplest way is to use a program called swaks, which you should find in your distro’s package library.

swaks -a -tls -q HELO -s mail.example.com -au test -ap '<>'

Should produce a result something like…

=== Trying mail.example.com:25...
=== Connected to mail.example.com.
.
.
.
 -> STARTTLS
<-  220 TLS go ahead
=== TLS started w/ cipher ECDHE-RSA-AES256-GCM-SHA384
=== TLS peer subject DN="/OU=Domain Control Validated/OU=PositiveSSL/CN=mail.example.com"
.
.
.
 ~> QUIT
<~  221 mail.example.com closing connection
=== Connection closed with remote host.

If you get an error when starting TLS examine your exim log for the cause.