FastMail 9 Months Review

You may remember that earlier this year, for reasons weakly linked to my change of employer, I have been looking to change my email provider. After many years using Gmail via what is now called Google Workspace, the complete disconnection to consumer features including Google One got to me, and I looked for an alternative.

At the time I considered both ProtonMail and FastMail as valid options — the former having been touted all over the place for their security features and privacy. After trying them both, and originally choosing the former, I found out that it would just not scale for the amount of email I had in Gmail, and instead switched over to FastMail, that seemed to fit much better for my needs.

Now it’s over nine months later, and I thought it’s a good time to check-in with my choice, and provide an update for the next person looking to choose an email provider. But before I get into the details, I think it’s also important to qualify that this year has been anything but “business as usual” — not just because of the lockdown, but also because me and my wife ended up moving to a new apartment, and oh, yeah I changed jobs. This means that my email usage pattern changed considerably, and that changed which features and values of FastMail I stressed on.

So let’s start with the elephant in the room, that is the offline availability — one of the things I noted earlier on is that the default Android app of FastMail is not much more than a WebView on a portable web app. It might not be technically precise, but I still feel it’s a good description for it. It does have some offline features, but you can’t “sync offline” a whole folder of email to have access to without a network connection. This would have probably been a much bigger, if not even deal-breaker, problem… if we had been traveling, or if I had been commuting two hours a day every day. But given the lockdown, this part is not really affecting me, nearly at all.

I guess that if this is a significant enough feature you need, using a “proper” client on the phone would be a good option — and that might have been something I’d have tried in different circumstances. As far as I can tell, FastMail does not implement OAuth2-based IMAP login flows, so you still need application-specific passwords for this to work, which I’m not really fond of — if they did, and they also supported U2F from phones (why is it not supported is not clear to me), that would be a total non-issue. As it is, it’s very low in my priorities though, so I’m not complaining.

Let’s segue that into security — as I said I’m still not sure why U2F is not supported on phones, and why I had to enable SMS 2FA to login on my Android phone. But on the other hand, it works fine on computers, so there’s that going on for us. FastMail is also the first provided that I see taking Application-Specific Passwords to the letter: when you create the password you can decide which scopes to attach to it, so if you want a send-only password, you can. And that makes life easier, and not just for developers needing to send kernel patches out.

So there’s space for improvement (OAuth2 and U2F, folks?), but otherwise I’m feeling confident that FastMail knows what they are doing and are taking compromises intentionally, rather than by coincidence.

On the Web UI side, things may be a bit bumpy — the UI feels “less fresh” than Gmail or Inbox, but that’s not entirely bad: it’s definitely lighter to use, and it makes searches work nicely. I think what I am missing from it is a more “native feeling” — I miss the contextual menu to archive or delete threads. The drag-and-drop works great though, so there’s that about it. Some of the choices of where to find actions (such as report spam/report non-spam) are a bit confusing, but otherwise it’s all very serviceable, and very customizable, too! The (optional) Gravatar integration is also fairly handy when talking with people in the FLOSS community, although I wish more services decided to provide a “service identity”.

If anything, there are two features I really miss from Gmail: the first is something that FastMail appears to have tried, and then given up on (for now), and that is the portable web app mode on desktop. For a while I had a FastMail window rather than a tab, and that was easier to handle for me. Having notifications running in the background without needing to have the tab open in my browser just make my flow easier (which is why I do that with Twitter, Home Assistant, and Google Maps among the others), and FastMail would be an obvious option there.

The second feature is the composer “pop up”. When having to deal with the horrible old property management company for the flat we lived in, I often had to go and refer back to previous threads, because they rarely would follow-up in writing, and the reference person changed all the time. I ended up having to open a second (or sometimes third) window open with the various searches, while composing a long message in the first one.

But otherwise? I haven’t been missing Gmail at all, despite the significantly higher amount of email I had to read and write due to the work and flat changes. Filters work fine, the self-deleting folders (or labels, you can choose which version you want!) are an awesome tool to keep the sheer amount of email under control.

Okay, sure, the “Smart Mail” features that I never had would have been nice at times — fill in the calendar with events just by receiving them! But as it turns out, GSuite/Google Workspace never got that feature in for their users. It’s long been a consumers-only feature, and so I never got into the habit of relying on it. And even when I had access to it, the fact that it required explicit enrolling of the providers by Google, it meant that only those services that had enough critical mass, or were used by a Googler, would be covered. It would be so much better if instead there would be better support for providers to attach, say, ICS files when they send you time-based information, such as expected delivery (for groceries, online shopping), or appointments (for hospitals and so on — although this is unlikely to happen: while NHS is very happy to remind me of all appointments in full by SMS, email messages only contains a “Please click here and put some obvious information about you to see the medical letter with the appointment”, alas.)

So, I clearly am a happy customer; even more so now that I have experience Outlook 365 (I can’t make heads or tails of that interface!) And I would say that, if you’re looking for an email-only provider, FastMail is the best option I have seen. Depending on what you’re looking for, Google Workspace might still a better value for money (with the whole collaboration suite), but I have a couple of former customers that I would probably have signed up on FastMail rather than Google, if they asked right now.

To close up, yes, there’s a referral programme nowadays — if you’re interested, this is my affiliate link. You’re welcome to use it, but it’s not the reason why I’m suggesting to use FastMail. I’m suggesting it because it is a terrific service.

Oh Gosh, Trying to Find a New Email Provider in 2020

In the year 2020, I decided to move out of my GSuite account (née Google Apps for Business), which allowed me to use Gmail for my personal domain, and that I have used for the past ten years or so. It’s not that I have a problem with Gmail (I worked nearly seven years for Google now, why would it be a problem?) or that I think the service is not up to scratch (as this experience is proving me, I’d argue that it’s still the best service you can rely upon for small and medium businesses — which is the area I focused on when I ran my own company). It’s just that I’m not a business and the features that GSuite provides over the free Gmail no longer make up for the services I’m missing.

But I still wanted to be able to use my own domain for my mail, rather than going back to the standard Gmail domain. So I decided to look around, and migrate my mail to another paid, reliable, and possibly better solution. Alas, the results after a week of looking and playing around are not particularly impressive to me.

First of all I discarded, without even looking at it, the option of self-hosting my mail. I don’t have the time, nor the experience, nor the will to have to deal with my own email hosting. It’s a landmine of issues and risks and I don’t intend to accept them. So if you’re about to suggest this, feel free to not comment. I’m not going to entertain those suggestions anyway.

I ended up looking at what people have been suggesting on Twitter a few times and evaluated two options: ProtonMail and FastMail. I ended up finding both lacking. And I think I’m a bit more upset with the former than the latter, for reasons I’ll get to in this (much longer than usual) blog post.

My requirements for a replacement solution were to have a reliable webmail interface, with desktop notifications. A working Android app. And security at login. I was not particularly interested in ProtonMail’s encrypt-and-sign everything approach, but I could live with that. But I wanted something that wouldn’t risk letting everyone in with just a password, so 2FA was a must for me. I was also hoping to find something that would make it easy to deal with git send-email, but I ended up accepting right away that nothing would be anywhere close to the solution that we found with Gmail and GSuite (more on that later.)

Bad 2FA Options For All

So I started by looking at the 2nd Factor Authentication options for the two providers. Google being the earliest adopter of the U2F standard means of course that this is what I’ve been using, and would love to keep using once I replace it. But of the two providers I was considering, only FastMail stated explicitly it supported U2F. I was told that ProtonMail expects to add support for it this year, but I couldn’t even tell that from their website.

So I tried first FastMail, which has a 30 days free trial. To set up the U2F device, you need to provide a phone number as a recovery option — which gets used for SMS OTP. I don’t like SMS OTP because it’s not really secure (in some countries taking over a phone number is easier than taking over an email address), and because it’s not reliable the moment you don’t have mobile network services. It’s easy to mistake the “no access to mobile network” with “no access to Internet” and say that it doesn’t really matter, but there are plenty of places where I would be able to reach the Internet and not receive SMS: planes, tube platforms, the office when I arrived in London, …

But surely U2F is enough, why am I even bothering complaining about SMS OTP, given that you can disable it once the U2F security key is added? Well, turns out that when I tried to login on the Android app, I was just sent an SMS with the OTP to log myself in. Indeed, after I removed the phone number backup option, the Android app threw me a lovely error of «U2F is your only two-step verification method, but this is not supported here.» On Android, which can act as an U2F token.

As I found out afterwards, you can add a TOTP app as well, which solves the issue of logging in on Android without mobile network service, but by that point I had already started looking at ProtonMail, because it was not the best first impression to start with.

ProtonMail and the Bridge of Destiny

ProtonMail does not provide standard IMAP/SMTP access, because encryption (that’s the best reason I can get from the documentation, I’m not sure at all what this was all about, but honestly, that’s as far as I care to look into it). If you want to use a “normal” mail agent like Thunderbird, you need to use a software, accessible to paying customers only, that acts as “bridge”. As far as I can tell after using it, it appears to be mostly a way to handle the authentication rather than the encryption per se. Indeed, you log into the Bridge software with username, password and OTP, and then it provides localhost-only endpoints for IMAP4 and SMTP, with a generated local password. Neat.

Except it’s only available in Beta for Linux, so instead I ended up running it on Windows at first.

This is an interesting approach. Gmail implemented, many years ago, a new extension to IMAP (and SMTP) that allows using OAuth 2 for IMAP logins. This effectively delegates the login action to a browser, rather than executing it inline in the protocol, and as such it allows to request OTPs, or even supporting U2F. Thunderbird on Windows does work very well with this and even supports U2F out of the box.

Sidenote: Thunderbird seems to have something silly going on. When you add a new account to it, it has a drop-down box to let you select the authentication method (or go for “Autodetect”). Unfortunately, the drop-down does not have the OAuth2 option at all. Even if you select imap.gmail.com as the server — I know hardcoding is bad, but not allowing it at all sounds worse. But if you cheat and give it 12345 as password, and select password authentication just to go through with adding the account, then you can select OAuth 2 as authentication type and it all works out.

Anyway, neither ProtonMail nor FastMail appear to have implemented this authentication method, despite the fact that, if I understood that correctly, it’s supported out of the box on Thunderbird, Apple’s Mail, and a bunch of other mail clients. Indeed, if you want to use IMAP/SMTP with FastMail, they only appear to give you the option to use application-specific passwords, which are a shame.

So why did I need IMAP access to begin with? Well, I wanted to import all my mail from Gmail into ProtonMail, and I though the easier way to do so was going to be through Thunderbird and manually copy the folders I needed. That turned out to be a mistake: Thunderbird crashed while trying to copy some of the content over, and I effectively was spending more time while waiting for it to index anything than instructing it on what to do.

Luckily there’s alternative options for this.

Important Importing Tooling

ProtonMail provides another piece of software, in addition to the Bridge, to paying customers: an Import Tool. This allows you to login to another IMAP server, and copy over the content. I decided to use that to copy over my Gmail content to ProtonMail.

First of all, the tool does not support OAuth2 authentication. To be able to access Gmail or GSuite mailboxes, it needs to use an Application-Specific Password. Annoying but not a dealbreaker for me, since I’m not enrolled in the Advanced Protection Program, which among other things disable “less-secure apps” (i.e. those apps using Application-Specific Passwords). I generated one, logged in, and selected the labels I wanted to copy over, then went to bed, a little, but not much, concerned over the 52 and counting messages that it said it was failing to import.

I woke up to the tool reporting only 32% of around fifty thousands messages imported. I paused, then resumed, the import hoping to getting it unstuck, and left to play Pokémon with my wife, coming back to a computer stuck exactly at the same point. I tried stopping and closing the Import Tool, but that didn’t work, it got stuck. I tried rebooting Windows and it refused to, because my C: drive was full. Huh?

When I went to look into it, I found a 436GB text file, that’s the log from the software. Since the file was too big to open with nearly anything on my computer, I used good old type, and beside the initial part possibly containing useful information, most of the file repeated the same error message about not being able to parse a mime type, with no message ID or subject attached. Not useful. I had to delete the file, since my system was rejecting writes because of the drive being full, but it also does not bode well for the way the importer is written: clearly there’s no retry limit on some action, no log coalescing, and no security feature to go “Hang on, am I DoSing the local system?”

I went looking for tools I could use to sync IMAP servers manually. I found isync/mbsync, which as a slightly annoyance is written in C and needs to be built, so not easy to run on Windows where I do have the ProtonMail bridge, but not something I can’t overcome. When I was looking at the website, it said to check the README for workarounds needed with certain servers. Unfortunately at the time of writing the document, in the Compatibility section, refers to “M$ Exchange” — which in 2020 is a very silly, juvenile, and annoying way to refer to what is possibly still the largest enterprise mail server out there. Yes, I am judging a project by its README the way you judge a book by its cover, but I would expect that a project unable to call Microsoft by its name in this day and age is unlikely to have added support for OAuth2 authentication or any of the many extensions that Gmail provides for efficient listing of messages.

I turned to FastMail to see how they are implementing it: importing Gmail or GSuite content can be done directly on their server side: they require you to provide OAuth2 access to all your email (but then again, if you’re planning to use them as your service provider, you kind of are already doing that). It does not allow you to choose which labels you want to import: it’ll clone everything, even your trash/bin folder. So at the time of writing it’s importing 180k messages. It took a while, and it showed the funny result of saying «175,784 of 172,368 messages imported.» Bonus point to FastMail for actually sending the completion note as an email, so that it can be fetched accordingly.

A side effect of FastMail doing the imports server side is that there’s no way for you to transfer ProtonMail boxes to FastMail, or any other equivalent server with server-side import: the Bridge needs to run on your local system for you to authenticate. It’s effectively an additional lock-in.

Instead of insisting on self-hosting options, I honestly feel that the FLOSS activists should maybe invest a little more thought and time on providing ways for average users with average needs to migrate their content, avoiding the lock-in. Because even if the perfect self-hosting email solution is out there, right now trying to migrate to it would be an absolute nightmare and nobody will bother, preferring to stick to their perfectly-working locked-in cloud provider.

Missing Features Mayhem

At that point I was a bit annoyed, but I had no urgency to move the old email away, for now at least. So instead I went on to check how ProtonMail worked as primary mail interface. I changed MX around, set up the various verification methods, and waited. One of the nice things of migrating the mail provider is that you end up realizing just how many mailing lists and stuff you keep receiving, that you previously just filed away with filters.

I removed a bunch of subscriptions to open source mailing lists for projects I am no longer directly involved in, and unlikely to go back to, and then I started looking at other newsletters and promotions. For at least one of them, I thought I would probably be better served by NewsBlur‘s newsletter-to-RSS interface. As documented in the service itself, the recommended way to use this is to create a filter that takes the input newsletter and forwards them to your newsblur alias.

And here’s the first ProtonMail feature that I’m missing: there’s no way to set up forwarding filters. This is more than a bit annoying: there was mail coming to my address that I used to forward to my mother (mostly bills related to her house, before I set up a separate domain with multiple aliases that point at our two addresses), and there still are a few messages that come to me only, that I forward to my wife, where using our other alias addresses is not feasible for various reasons.

But it’s not just a matter of forwards that is missing. When I looked into the filter system of ProtonMail I found it very lacking. You can’t filter based on an arbitrary header. You cannot filter based on a list-id! Despite the webmail being able to tell that an email came through from a mailing list, and providing an explicit Unsubscribe button, based on the headers, it neither has a “Filter messages like these” like Gmail has, nor a way to select this manually. And that is a lot more annoying.

FastMail, by comparison, provides a much more detailed rules support, including the ability to provide them directly in Sieve language, and it allows forward-and-delete of email as well, which is exactly what the NewsBlur integration needs (although to note, while you can see the interface for do that, trial accounts can’t set up forwarding rules!) And yes, the “Add Rule from Message” flow defaults to the list identifier for the messages. Also, to one-up even Gmail on this, you can set those rules from the mobile app as well — and if you think this is not that big of a deal, just think of much more likely you are to have spare time to do this kind of boring tasks while waiting for your train (if you commute by train, that is).

In terms of features, it seems like FastMail has the clear upper hand. Even ignoring the calendar provided, it supports the modern “Snooze” concept, letting mail show up later in the day or the week (which is great when, say, you don’t want to keep the unread email about your job interviews to show up on your mail inbox at the office), and it even has the ability to permanently delete messages in certain folders on after a certain amount of days — just like gmaillabelpurge! I think this last feature is the one that made me realize I really just need to use FastMail.

Sending It All Out

As I said earlier, even before trying to decide which one of the two providers to try, I gave up on the idea of being able to use either of them with git send-email to send kernel patches and similar. Neither of them supports OAuth2 authentication, and I was told there’s no way to set up a “send-only” environment.

My solution to this was to bite the bullet and deal with a real(ish) sendmail implementation again, by using a script that would connect over SSH to one of my servers, and use the postfix instance there (noting that I’m trying to cut down on having to run my own servers). I briefly considered using my HTPC for that, but then I realized that it would require me to put my home IP addresses in the SPF records for my domain, and I didn’t really want to publicise those as much.

But it turned out the information I found was incorrect. FastMail does support SMTP-only Application Specific Passwords! This is an awesomely secure feature that not even Gmail has right now, and it makes it a breeze to configure Git for it, and the worst that can happen is that someone can spoof your email address, until you figure it out. That does not mean that it’s safe to share that password around, but it does make it much less risky to keep the password on, say, your laptop.

I would even venture that this is even safer than the sendgmail approach that I linked above, as the other one requires full mail access with the token, which can easily be abused by an attacker.

Conclusion

So at the end of this whole odyssey, I decided to stick with FastMail.

ProtonMail sounds good on paper, but it give me the impression that it’s overengineered in implementation, and not thought out enough in feature design. I cannot otherwise see how many basic features (forwarding filters, send-only protocol support — C-S-c to add a CC line) would otherwise be missing. And I’m very surprised about the security angle for the whole service.

FastMail does have some rough edges, particularly on their webapp. Small things, like being able to right-click to get a context menu would be nice. U2F support is clearly lacking: having it work on their Android app for me would be a huge step forward. And I should point out that FastMail has a much friendlier way to test its service, as the 30 days free option includes nearly all of the functionality and enough space to test an import of the data from a 10 years old Gmail.

Why is `git send-email` so awful in 2017?

I set myself out to send my first Linux kernel patch using my new Dell XPS13 as someone contacted me to ask for help supporting a new it87 chip in the gpio-it87 driver I originally contributed.

Writing the (trivial) patch was easy, since they had some access to the datasheet, but then the problem came to figure out how to send it over to the right mailing list. And that took me significantly more time than it should have, and significantly more time than writing the patch, too.

So why is it that git send-email is still so awful, in 2017?

So the first problem is that the only way you can send these email is either through a sendmail-compatible interface, which is literally an interface older than me (by two years), or through SMTP directly (this is even older, as RFC 821 is from 1982 — but being a protocol, that I do expect). The SMTP client has at least support for TLS, provided you have the right Perl modules installed, and authentication, though it does not support more complex forms of authentication such as Gmail’s XOAUTH2 protocol (ignore the fact it says IMAP, it is meant to apply to both IMAP and SMTP).

Instead, the documented (in the man page) approach for users with Gmail and 2FA enabled – which should be anybody who wants to contribute to the Linux kernel! – is to request an app-specific password and saving it through the credential store mechanism. Unfortunately the default credential store just stores it as unencrypted plaintext. Instead there are a number of credential helpers you can use, either using Gnome Keyring or libsecret, and so on.

Microsoft maintains and releases its own Credential Manager which is designed to support multi-factor login to a number of separate services, including GitHub and BitBucket. Thank you, Microsoft, although it appears to only be available for Windows, sigh!

Unfortunately it does not appear there is a good credential helper for either KWallet or LastPass which would have been interesting — to a point of course. I would probably never give LastPass an app-specific password to my Google account, as it would defeat my point of not keeping that particular password in a password manager.

So I start looking around and I find that there is a tool called keyring2 which supposedly has kwallet support, though on Arch Linux it does not appear to be working (the kwallet support, not the tool, which appear to work fine with Gnome Keyring). So I checked out the issues, and the defaulting to gnome-keyring is known, and there is a feature request for a LastPass backend. That sounds promising, right? Except that the author suggests building it as a separate library, which makes sense to a point. Unfortunately the implicit reference to their keyrings.alt (which does not appear to support KDE/Plasma), drove me away from the whole thing. Why?

License is indicated in the project metadata (typically one or more of the Trove classifiers). For more details, see this explanation.

And the explanation then says:

I acknowledge that there might be some subtle legal ramifications with not having the license text with the source code. I’ll happily revisit this issue at such a point that legal disputes become a real issue.

Which effectively reads to me as “I know what the right thing to do is, but it cramps my style and I don’t want to do it.” The fact that there have been already people pointing out the problem, and the fact that multiple issues have been reported and then marked as duplicate of this master issue, should speak clearly enough.

In particular, if I wanted to contribute anything to these repositories I would have no hope to do so but in my free time, if I decide to apply for a personal project request, as these projects are likely considered “No License” by the sheer lack of copyright information or licenses.

Now, I know I have not been the best person for this as well. But at least for glucometerutils I have made sure that each file lists its license clearly, and the license is spelt out in the README file too. And I will be correcting some of my past mistakes at some point soon, together with certain other mistakes.

But okay, so this is not a viable option. What else remains to use? Well, turns out that there is an actual FreeDesktop.org specification, or at least a draft, which appears to have been last touched seven years ago, for a common API to share between GNOME and KWallet, and for which there are a few other implementations already out there… but the current KWallet does not support it, and the replacement (KSecretService) appears to be stalled/gone/deprecated. And that effectively means that you can’t use that either.

Now, on Gentoo I know I can use msmtp integrated with KWallet and the sendmail interface, but I’m not sure if in Arch Linux it would work correctly. After all I even found out that I needed to install a number of Perl modules manually, because they are not listed in the dependencies and I don’t think I want to screw with PKGBUILD files if I can avoid it.

So at the end of the day, why is git send-email so awful? I guess the answer is that in so many years we still don’t have a half-decent, secure replacement for sending email. We need what they would now call “disruptive technology”, akin to how SSH killed Telnet, to bring up a decent way to send email, or at least submit Git patches to the Linux kernel. Sigh.

Update 2020-08-29: if you are reading this to try to make sense on how to use git send-email with Gmail or GSuite, you may want to instead turn to the sendgmail binary released in the gmail-oauth2-tools repository. It’s not great, particularly as the upstream maintainer has been very non-responsive, even when I was a co-worker, and it’s not the easiest thing to setup either (it needs you to have a Google Cloud account and enable the right API key), but it does work. If you feel like forking this, and merging the requisite pull requests, and release it as its own application, please be my guest. I’m not using Gmail anymore myself, so…

My approach to paranoia: electronic bills

One thing that I’ve been told about my previous post is that I sounded paranoid. I may be, I”m not as paranoid as the kind of people who fear the NSA in my book.

We have plenty of content out there (I would venture a guess that most of it is on reddit, but don’t take my word for it) where paranoids describe all the kind of shenanigans they go through to avoid “The Man”. I thought I may as well put out there what I do in my “paranoia”, and I’ll start with my first tenet: Email is safer than snail mail.

We all know the Snowden revelation made people fret to find new email protocols and all that kind of stuff. But my point of view is that if someone wants to steal my mail (for whatever reason), they only have to force the very simple lock of my mailbox, or use some tool to take the envelopes out from the same opening that is used to put content in.

This might be not so obvious for my American readers, as I found recently that the way USPS’s monopoly on mail delivery is enforced is by not letting anybody put stuff in your mailbox but the postman. Although I’m pretty sure that you can find black market keys for it. In Europe at least, mailboxes are not accessible by the postmen, and anybody can put envelopes in. In Italy in particular, TNT (the Dutch company) for a while ran a delivery service for mail, rather than packages. Both my bank, my mobile phone provider and me (to send mail to customers) used it because of the higher reliability.

So in this vein, I favour any kind of electronic communication over paper trail. This is not difficult in most countries right now; in particular in Italy it started more than five years ago with my landline and ADSL provider: not only they allowed me to receive their bills by email rather than snail mail, but they waived a €1.5/bill fee for delivery. Incidentally, this only worked if you had direct debit enabled, which I did because the bills kept arriving late, after expiration date passed, and we kept paying fines for that. As of today, the only bill that still arrives in the snail mail to my mother in Italy is the gas bill, and that’s only because we don’t use a city gas feed. This is especially handy as I’m the one paying said bills, and I’m no longer in Italy.

In Ireland, things are mostly okay, but not perfect: both my previous and current electricity and gas providers allow electronic bills, but the new one only allowed me to opt-in after I received the first two bills. Banks are strange — my first bank in Ireland was fully electronic, with the exception of inbound wires (which were pretty common for me due to Autotools Mythbuster and expense reimbursement for work travel); my current bank sends me the quarterly statements by mail, even though I have access to them on their website, but they do seem to have some problem with consistency and reliability. My Tesco VISA unfortunately does mail me the monthly statement by post, as they don’t have an online banking site for Irish customers (they do for British ones, but let’s not go there.) My American bank is totally paperless (which is very good for me, as I need to have my US mail forwarded), to the point that receiving rebate checks, I only needed my mobile phone to deposit them.

But there is a much more important piece of paper, that I kept receiving after I moved to Dublin: my payslip. It’s probably not obvious to everybody but this is my first “proper” employment. Before I had contracts, and freelanced, and had my own “company”, so I would send and receive invoices, but never received a payslip before joining the company I work for now. And for a few long months I would receive the paper copy of it in my mailbox at the end of the month. I don’t think there is much more private than your salary, so this was bothering me for a while — luckily we now moved to an external online provider, so no more paper trail for this.

The question becomes how to handle the paper that you do receive. I already wrote a long time ago about my dream of a paperless office, and I have bought a professional EPSON scanner, as having your own company generates a huge amount of paper. While I don’t use it with the same workflow as I had before, I still scan all the paper I receive in the mail, and then destroy it fully.

In Italy I had a shredder: I would shred any paper at all, whether it contained personal information or not; my point is that even if someone was dumpster diving into my personal shredded paper, they would end up finding the most recent promotional spam from TeamViewer or MediaMarkt. There are nasty problems with having a shredder: it’s extremely noisy, it creates tons of dust, and you have to clean it manually which takes a lot of time. You have no idea how bad my home office was after I finished running the whole set of historical documents of the family!

Here things got lucky, instead of dealing with a home shredder, my office uses a shredding company services, so I just need to bring the papers with me and throw them in the dedicated bins. This makes it much simpler to deal with the trickling paper trail of mail (and boarding passes, and so on…).

I have multiple copies of all the PDFs scanned documents: Google Drive, Dropbox and an encrypted USB flash stick, to make it safe. So unless the interested attacker gets access to my personal accounts, there is no way to access that information.

What’s a valid email address?

In my daily job (which actually was a weekend job, but that’s beside the point now), I’ve recently had to extend a regular expression that is used for validating a string as an email address. It made me shiver, because it does not really work, and I don’t like having to make changes that don’t really work, but just seem to.

The email address format is quite complex, and indeed you really cannot be sure about the validity of an email address until you actually try to deliver something to that. But trying to get it right with a simple regular expression is deemed to fail, for very good reason.

Indeed if you Google for “valid email address regexp” you are brought to an interesting article about valid email address and regular expressions that gives you a lot of very interesting information. Although I don’t agree with all of it, and I’m sure they are also not counting on at least a few important things.

In particular, I got two email addresses that didn’t work properly in the regular expression, the first fixed the second not: flameeyes+something@gmail.com (which is an extension of my usual email address) and diego.elio@pettenò.es (which is my email using IDN domain). Now, the latter is not really well supported out there, because of the security risks for homograph attacks and in anti-Unicode developers out there; the former instead is a very common and standard form for addresses and should thus taken into consideration. If you follow what the article above says, you would also probably go around rejecting or removing the string “nospam” from addresses; a long time ago, my email address when posting on Usenet and elsewhere was nospam@daps.cjb.net … a simple redirect to my main email address, but a lot of spambots decided to remove “nospam” and ended up without an username part to send their email. Fun isn’t it?

Now, there is no way you can find a way to whitelist all the possibly valid email addresses out there; the obvious way would be to just allow a subset, as the article I listed above suggested, and deal with problems on a case by case basis. I don’t like that approach, because a single user that does try to use his (valid) email address and finds it refused is often a scorned user (it happened to me way too many times with just using the extension, I don’t really use normally the IDN domain).

What is my suggested approach then? Well, since you can be sure that an email is 100% valid, you should work it on the other way: reject what you’re sure is invalid, and then let the rest through; the possible rejected messages are probably less bothersome than users being unable to register or not getting the mail they expect. So how would I do that?

First of all, I’m afraid I have to say I don’t know well enough the email standards to know exactly what is and what is not allowed to a certainty, which means I would have to document myself to write code to do that; I would probably do it, if I needed to, but right now my job does not require me to do this (the code that I “fixed” is already legacy), and thus I won’t be doing this very likely.

Anyway the general sense of rules I can be sure enough of is that there are different validation rules for the two parts that compose an email address: the username and the domain (which can actually not be a domain at all, but let’s get back to that later). For instance in the username you can have the + symbol that selects an extension, but you cannot have it in the domain part. So my first step would be divide the two parts, this also has the nice side effect of ensuring that the at-symbol is present.

Now you get to validate the username, with whatever rules there are for allowed characters (I have no idea whether punycode is used or which character classes are needed; for sure they are documented, somewhere. I remember it has to start with letters or numbers, no special characters; I’m not sure if all but a few characters are valid or not. Whatever the way you can make sure that the username at least looks valid much more easily that you can check a domain.

For the domain part, well, you have some more complicated choices; the article above does an offline check on validity of the domain; this makes sense to a point, but I sincerely prefer a more thorough route:

first the domain part can actually be a host, in the form of [127.0.0.2], and that case should probably be considered, as well;
second the domain part can be IDN-based, and if you do support them (you should) you probably want to make sure it’s correctly encoded in punycode, there are IDN libraries out there that can take care of that;
once you have the domain cleaned up and eventually punycode-encoded, you can check with DNS whether it has an MX record or not; this solves all the crazy talk that the article above has about supporting .museum or checking against .nospam; DNS resolution is usually fast enough that you can check this inline in the registration; given that most users will use the same email providers, having a local cache like nscd can help lots;
if you really want to check that the email is not absolutely invalid, you may want to try connecting to the mail server, and ask if the user exists; this won’t work on most servers, but you can probably cut down some more invalid addresses this way.

Now of course this is no trivial logic that has to be implemented, and it becomes even more problematic if you also want to label the email addresses with the sender’s name, since the RFC gets so obscure that even git fails to meet the specifications that vger (the Kernel.org mailing list server) wants respected! For this reason maybe this is more suited for a library, if it doesn’t exists already; if somebody knows of something that do verify email addresses this way, please do let me know, I’m interested (Ruby and Python mostly but whatever is good).

Some thoughts about spam email

I’m so tired of spam messages in my mailboxes. The amount of spam increases monthly, and even if most of my spam is filtered out by GMail’s fantastic spam filter, I still receive lots that I need to categorize manually every day. In particular, in the past week I started receiving mail that was allegedly sent by me.

This starts to feel very stupid especially since, after years from the start of the problem, we haven’t been able to resolve the situation at all. Software has been refined to mark email with better precision, but the source of the problem is still there. What does this tell me?

Often I hear the argument that if spam wasn’t a business, we wouldn’t be seeing any, so the cause of the spam continuing is the fact that people do actually buy stuff from spammers. I’m not entirely sure of this reasoning. Yeah okay the reason why phishing continues is because people actually fall for it often enough, making it profitable for frauders, even when the risk of being caught is sensibly higher. On the other hand, I start to wonder who is the spam profitable to.

If I look at the spam I started to receive lately, it’s not always sent to sell me stuff, and while sometimes I see german spam that seems to have some kind of political objective (that is most likely not going to be helped by the spam itself, but whatever), I get huge amount of spam that just seems to be used to get around filters, and be annoying. Maybe they try to poison the spam filters, or maybe…

Who’s currently having heavy profits from spam emails? Producers of spam filters, consultants who sell configuration of SpamAssassin, and most importantly, providers of combined spam filtering services. My ISP is selling special email accounts with better spam filtering, instead of providing it to its users as a basic service. I hear people talking about mail clusters with multiple input, output and processing servers; I always thought that mail protocols were quite lightweight, I sincerely doubt this was the case before spam was an issue.

In the reasoning I cited above there is one thing that is for sure: spam will continue as long as it’s profitable. The problem is who is it profitable to? What can we do to make it not profitable any longer?

Russian spam

I had already titled the blog when I saw that Robin had written something about spam too. Robin, I have had my share of similar spam, and there is somone who has been reporting it on Planet Debian too. This spam is starting to get increasingly hard to filter. On a different note Peter Zaitchev posted a similar entry on Kernel Planet.

My beef in the last few days has been with Russian spam instead. It has been month since I started receiving this kind of spam, but usually it was a few mail over a week. Lately instead it has been tons of them.

Why does it bother me? Well first of all because it seems GMail doesn’t seem to identify that kind of spam that well. I fed a few hundreds of it in their spam folder and it still hasn’t been detected. At first I thought it was a matter of it being written in a language different than English, but it detects my ISP’s advertisement as spam already (after forcing hundreds of that in the Spam folder).

But it’s not just that, there are tons of spam that pass uncaught, and even more that is actually caught by GMail and never reaches me (I only ever had a couple of false positives up to now as far as I know). What really drives me crazy is the uselessness of this spam!

I can “understand” Nigerian scams as they try to get money out of people who can’t understand that an old lady would never write to someone she has never seen in her life to transfer the whole national treasure of Nigeria. But what the heck do those Russian want from me? I cannot read Russian in the first place! If you want to spam in Russian, do so only to .ru addresses! Otherwise at least translate it in English (which incidentally I’d expect GMail to handle better)!

Really what drives me crazy is that the only achievement of that spam in my case is to give me tons of noise in my Inbox. I woke up today with 12 new messages, all spam, 3 in English, the rest in Russian.

Really annoying!