Sieve filters that will increase ProtonMail security

In addition to encryption and two-factor authentication ProtonMail also incorporates the Sieve programming language which can be used to filter your emails with greater customization.

You can check the ProtonMail website for Sieve rules that allow you to customize your email filters to better organize your mailbox, however in this article I’ll be going over the rules that I’ve added to my ProtonMail account so that I’m protected against security threats and phishing attacks.

Rule #1: Detect emails that are not encrypted using SSL/TLS

ProtonMail’s main claim to fame is it’s OpenPGP end-to-end encryption. However this encryption only works when you’re emailing with other ProtonMail users or other users who are using PGP.

If you’re just emailing with your Mom who uses Gmail then the email will not be PGP encrypted. Instead it will be SSL/TLS encrypted. This level of encryption provides security from eavesdroppers who might be listening in on the connection between you and the Gmail servers that your Mom uses for her email.

But what if someone you communicate with doesn’t use an email service that encrypts using SSL/TLS? The email will be sent in plain text exposing it’s data to the internet.

This first rule will alert you when an incoming email is not using SSL/TLS encryption. This will allow you to be careful with your reply knowing that the message will be readable to whoever might be listening on the internet.

require "fileinto";

# Put all mails that have been sent without TLS/SSL into the spam folder and apply the no TLS label

if header :is "x-pm-transfer-encryption" "none" {
    fileinto "NO TLS/SSL";
    fileinto "Spam";
}

The rule will apply the “NO TLS/SSL” label (you’ll need to create this) and then file the message into the spam folder for you to review.

Rule #2: Detect emails that fail anti-spoofing checks

Email is a standardized service and incorporates several checking mechanisms in the background to try to prevent anti-spoofing and anti-phishing attacks from malicious actors that try to impersonate the people that you communicate with.

Two of those technologies are SPF and DKIM. You can use a search engine to get a better understanding of these. A rule that I find useful is one that will alert me when an email fails SPF or DKIM. This helps me to avoid responding to emails that might be impersonation attacks.

require ["fileinto", "imap4flags"];

# mark emails that have failed basic anti-spoofing

if anyof(
      header :contains "Authentication-Results" "dkim=fail",
      header :contains "Authentication-Results" "spf=fail",
      header :contains "Authentication-Results" "spf=none") {
      fileinto "AUTH-FAIL!";
      fileinto "Spam";
stop; 
}

Emails that either fail SPF or DKIM, or emails that have no SPF (also a risk), will be labeled with “AUTH-FAIL!” (make this label first) and then filed into spam for you to review.

Note: You may wish to remove the spf=none rule. I include it because most people that I communicate with are using an email platform that includes SPF but if you’re communicating with people on older platforms or with people who have not setup SPF on their custom domain then you may find too many emails being caught by this.

Note 2: You may find newsletters triggering this rule.

Rule #3: Block impersonation attacks on your trusted contacts

The final rule is used on an individual contact. If you communicate regularly with a friend and would like to increase the level of confidence that an email has actually come from her and not from someone pretending to be her then the following rule will try to alert you to impersonation attacks:

require ["fileinto", "imap4flags", "envelope", "include"];

# check for mismatch between sender values for contact1

if allof(
    address :is "from" "contact1@domain.com",
    exists "reply-to",
    not header :is "reply-to" "contact1@domain.com")
     {
          fileinto "PHISHING!";
          fileinto "Spam";
          stop; 
     }  
elsif allof (
   address :is "from" "contact1@domain.com")
     { 
         fileinto "Contact1";
     }

Simply replace “contact1@domain.com” with the email address of your friend.

This will compare the “from” field in the header of the email with the “reply-to” field. A mismatch between these two values will suggest that someone is trying to pretend to be your friend.

A side-benefit here is that the rule will label legitimate emails with the name of your contact.

What else?

I recommend that you implement all three rules in the order listed in this article to be protected by all three checks. This will ensure that emails arriving to your inbox are encrypted using SSL/TLS, have passed SPF and DKIM, and your contacts are not being impersonated.

As always: you use these at your own risk and no rule or safe guard provides 100% protection. There are other attacks that these rules will not catch.

What rules are you guys using to increase security and safety with ProtonMail? Post them in the comments below.