Steps to improve your spam filtering

This post is a summary explaining the common measures people can take to improve the spam filtering in their account.

  1. Turn on advanced spam filtering
    • Go to the Options -> Spam / Virus protection screen and switch from “Basic” to “Normal”, “Aggressive” or “Custom” level filtering (subscription accounts only)
  2. Avoid using forwarding services
    • If you forward email from an old email address, tell people to use your @fastmail.fm/@sent.com/etc address instead and close down forwarding from the old system.
    • If you use your own domain, point the MX records for your domain directly at our servers (Enhanced or family/business accounts only)
  3. Report spam and non-spam emails
    • If you report more than 200 spam and 200 non-spam emails, it will activate your personal bayes database. This will significantly increase the scoring accuracy of the spam filter on your email
    • See the bottom of the Options -> Spam / Virus protection screen to see how many spam and non-spam emails you’ve reported
    • If you use IMAP mostly, setup auto-reporting on folders. Login and go to Options -> Folders. Set the “Learn as non-spam” property on folders that you store known non-spam emails in (eg folders you archive emails into). Create a folder called “Learn spam”, and set the as “Learn as spam” and “Purge > 7 days old” properties on it. Then from your IMAP client, drag any spam emails you receive into that folder to learn them + delete them
  4. Add known senders to your address book
    • Email from senders in your address book get special treatment. They avoid greylisting and get a reduced spam score
    • The checking will occur on the SMTP MAIL FROM envelope, the “From” header, and the “Sender” header

A more detailed post will follow explaining the technical underpinning of these shortly.

Posted in News. Comments Off

Opportunistic SSL/TLS encryption on incoming emails

FastMail now enables opportunistic SSL/TLS encryption on incoming emails. This means we now advertise STARTTLS support in response to an EHLO command on our MX servers.

Trying 66.111.4.70...
Connected to mx1.messagingengine.com.
Escape character is '^]'.
220 mx1.messagingengine.com ESMTP . No UCE permitted.
EHLO blah.com
250-mx1.messagingengine.com
250-PIPELINING
250-SIZE 71000000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME

If the server sending the email to FastMail supports it, it will enable an SSL/TLS connection and send the email to FastMail over an encrypted connection. Some extra notes:

  • At the moment, this only affects the sending of email from another server to FastMail, not from FastMail to another server, though we are looking into this
  • We can’t force a remote server to use encryption, it’s up to the remote server to detect that we support it and then enable it before sending the email
  • This is not full end-to-end encryption of the email. The email is only encrypted during transit from the other server to us, once at our side, it’s stored unencrypted again. For full end-to-end encryption, you need something like PGP
  • Encrypted connections have extra headers added to the email so you can see the transmission was encrypted. An example:

Received: from remoteserver.com (remoteserver.com [a.b.c.d])
    (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
    (No client certificate requested)
    by mx1.messagingengine.com (Postfix) with ESMTPS id 8FDBA27063B
    for <sam@fastmail.fm>; Wed, 15 Apr 2009 23:28:29 -0400 (EDT)

Since this feature is entirely optional, it shouldn’t affect any sending servers that don’t support STARTTLS, and thus shouldn’t affect the deliverability of email in any way.

Posted in Technical. Comments Off

Removal of "bounce" feature from web interface

For a long time, FastMail has had a “bounce” action in the web interface. When applied to email(s), it would generate a standard looking “bounce” email back to the sender, making it look like the original email delivery had failed.

This feature has now been removed from the web interface because it now causes many more problems than it solves.

The problem is that when the feature was first created, most emails had valid “From” addresses. These days the “From” address on most unwanted emails are forged and random, so bouncing an email really just generates backscatter emails, which themselves are considered spam. So rather than stopping spam, the bounce feature actually just generates more spam to other people!

On top of that, the bounces can cause our servers to be listed on IP blacklists. For instance, a user bouncing a large number of messages over a couple of days several months back caused most of our outgoing server IPs to be listed at http://www.backscatterer.org/. Having any of our outgoing server IPs listed on any RBL blacklist is a bad thing, because there are always systems out there using obscure RBLs like this (and worse, sometimes incorrectly configuring them to reject all email rather than just postmaster <> empty address bounce emails), which then means other users get emails they’re trying to send bounced, which is always bad.

Although there are one or two cases where bouncing might be useful, they’re rare compared to what people are actually doing, and these days, it’s much better to do the following actions:

  • For spam, just use the “Report spam” action to help train your personal bayes database to better recognise spam in the future
  • For unwanted email repeatedly from the same sender, just go to Options -> Define Rules and create a discard rule to delete any future email from that sender
Posted in News. Comments Off

Improved email address tokeniser on /beta/

The new web interface attempts to convert email addresses put in the To/Cc/Bcc boxes on the compose screen into “tokens”. However there were a number of bugs with the current implementation listed on our wiki bug page:

  1. Email addresses surrounded by ‘ (single quotes) were handled poorly, partly disappearing, but still being left in the data sent back to the server
  2. Email addresses where the “phrase” part had more than one , (comma) in it were split incorrectly. For example: “smith, john, help center” <johnsmith@example.com>
  3. Email addresses where the “phrase” part had a angle-bracketed address were handling incorrectly. For example: “<johnsmith@example.com>” <johnsmith@example.com>

I’ve now completely rewritten the address parser, and put it on our beta server for testing. The new parser fixes all of the above problems, should be more resilient to odd address formats, and now allows you to do things like paste a list of email address with only spaces between them (rather than having to put commas) and it should tokenise them correctly.

If you come across any new problems, please email me directly at robm@fastmail.fm with details including an example of how to reproduce the problem and I’ll look into it.

Update 16-Apr-2009: Since there were no reported problems, I’ve now rolled out the new tokeniser to the production servers.

Posted in Technical. Comments Off

Beware phishing emails sent to FastMail customers

We started receiving reports yesterday that FastMail customers were receiving phishing emails asking for their FastMail account password. These emails claimed to be from “The fastmail.fm team” and ask you to reply with your password and that “Failure to do this will immediately render your email address deactivated from our database“.

These emails are a scam, do not reply to them. We will never send out emails asking you for your password.

I’ve already put blocks in place to try and stop any more of these emails arriving, and I’ve put a block in place so anyone accidentally replying to the email will have their reply blocked so they don’t accidentally send their password to these scammers. I’ve also checked the logs for anyone that did accidentally reply, and will inform them that they should update their account details.

Posted in News. Comments Off
Follow

Get every new post delivered to your Inbox.

Join 4,633 other followers