General
Coding Projects
Links
Other Pages Here
Thunderbird Anti-Phishing/Sender Verification Extension
By Joshua Tauberer

Protect Yourself From Phishing

This is an extension for the Mozilla Thunderbird email application that reports, when possible, whether the sender shown in the From: header was actually the sender of the email. In fact, forging the From: header is possible! This is intended to be a tool to identify phishing, fradulent emails asking for your sensitive data, and zombie-spread viruses claiming to be from someone they are not. The extension uses Sender Policy Framework (SPF) (in a nonstandard way) and DomainKeys (DK) to verify the sender's domain, and SURBL, Spamhaus, DNSWL, and Sender Score Certified for reputation information.

What it does and doesn't do: The extension checks the domain name (e.g. aol.com) in the From: header, but not the user name part (e.g. the "my.name" part in my.name@aol.com). And since many domains don't support SPF or DK, emails claimed to be from these domains can't be verified with the methods used by the extension. These new email protocols aren't perfect, and neither is the extension, so positive verification results should be interpreted with common sense.

"Sender Verification" lines show the results of verification checks performed by the extension.

Download

Right-click this link ---> download <--- and choose "Save Target As" or "Save As" to save the file to your computer. Then in Thunderbird, go to Tools > Add-ons and install the file you downloaded. You can also get the extension from Mozilla Add-ons, and if you do it that way it will automatically check for updates. I post things here first, though.

Mail List

This open but moderated Yahoo! mail list for the extension is a good place to post suggestions and bugs. Or contact me directly.

Source Code

Here's the source code (public domain): extension .tgz, SenderVerification.pm and query.cgi for answering DK queries, browse code, or anon SVN at svn://razor.occams.info/thunderbird-spf.


Latest Version

The current version of the extension is 0.9.0.1, posted September 10, 2007. This version now looks up addresses in your address book to see if they are known to you or are new to you, and consults DNSWL.org (working as of 0.9.0.1) and Sender Score Certified, DNS-based whitelists, to obtain any positive reputation information they may have.


Using the Extension

The extension sits at the top of every email message and reports the verification status of the sender. Here are some of the messages you will see:

Domain <example.com> Confirmed.
The domain name (i.e. "yahoo.com", "aol.com") shown in the "From:" line was confirmed using the Sender Policy Framework (SPF) or DomainKeys (DK) verification process. You can be reasonably sure that the sender is legitimately using the domain shown; however, the user name part of the address (i.e. "mike" in "mike@aol.com") is never checked by this extension. And, a confirmed domain does not mean that the domain is necessarily trustworthy. Also watch out for domain-lookalikes!
Reputable Sender
The domain of the sender (e.g. "aol.com") was listed in a 3rd party list of reputable senders. You can be reasonably sure that the domain shown is trustworthy (but always use common sense). DNSWL and Sender Score Certified are the sources of the reputation information for this message.
"From:" domain unverified. Envelope domain <example.com> confirmed.
Sometimes the domain listed in the "From:" address cannot be positively or negatively verified. An alternate domain listed in the hidden envelope information of the email has been confirmed as the sender of this email (the domain shown in the message), and you should use this envelope domain, and not the "From:" address, when considering whether to trust the sender. The "From:" address is likely forged (which doesn't necessarily indicate maliciousness, but it may).
This does not appear to be a legitimate <example.com> email.
The verification process indicates that the sender was likely not authorized to send mail using the domain in the "From:" address. While this can indicate malicious intent, it may also result from an inadvertently incorrect mail configuration on the sender's side. There is also an inherent limitation in the verification process that causes this message to show up on emails from senders using the same ISP as you, generally for small ISPs.
Sending domain does not support verification (address could be forged).
Mail list domain could not be verified or does not support verification.
The domain indicated in the "From:" address (e.g. "aol.com") or the hidden envelope address does not support verification. When a sender is not verified, it does not mean the email is necessarily forged. Some web domains do not participate in new verification systems, and emails claming to be from them may not always be able to be positively verified.
Sending domain could not verify sender (address could be forged).
While the domain indicated in the "From:" address (e.g. "aol.com") supports verification, the sender could not be positively or negative verified. When a sender is not verified, it does not mean the email is necessarily forged, but that is certainly one reason this message will appear.
This sender is a known malicious spammer or phisher. Discard this email.
The sender was listed in a 3rd-party list of spammers or malicious phishing attack senders, by IP address or by the domain shown in the "From:" or hidden envelope addresses. When this message appears, you can be very certain that the sender is malicious. SURBL and Spamhaus are used for this check.
Address is known to you.
Domain is known to you.
Sender is unknown to you.
Unless other reputation information is available for the sender, the extension looks inside your Address Book to see if the address shown in the "From:" address is someone you have corresponded with before. This message reports whether the full address ("Address is known to you.") or just the domain (e.g. "@aol.com"; "Domain is known to you.") was found in your address book, or if not even the domain was found in your address book ("Sender is unknown to you."). Obviously, whether you can trust a domain found in your address book rests on whether you are sure you have not included any malicious senders in your address book, which may have automatically ocurred if you simply replied to a malicious address.
Message is confirmed from a <example.com> mail list.
The original sender of mail list email is not checked by the extension. Rather, the extension checks whether the email is legitimately from a mail list at the indicated domain. You may not be able to trust the body of the message, or the sender shown in the "From:" address, but at least you can confirm which mail list relayed the email to you.
Message is too old to verify sender.
The message verification techniques rely on transient information. Stored messages from too long ago cannot be verified.
Mail originates from your mail server, or message headers could not be understood.
This is a catch-all message when certain information about the email could not be found in the email. This is the case when the message originates from your ISP directly, or from users with local accounts on your mail server. The message could not be verified. If you are sure the message originated externally from your ISP, please contact the developer of this extension to report the message as a bug.
Sender verification is not applicable for this message.
Emails opened from .eml files on disk, and other types of messages besides those from POP and IMAP servers, cannot be verified.

Brief FAQ

FAQ: Can the extension tie into mail filters to move forged emails into my junk folder?

No, and you wouldn't want to do that anyway. Whether an email passes or fails a verification check doesn't say much about whether it is definitely spam or phishing. Many "bad" emails will correctly pass the check because spammers are sending verified emails, and many legitimate emails will be labeled as forged or unverified because of unusual email transport conditions. The extension is meant as a tool for a human with some common sense to interpret, not a machine.

FAQ: I know a domain doesn't use SPF or DK, but the email is shown as verified. How could that be?

Because so few domains actually publish SPF records, the extension uses the usual SPF "guess" mechanism when no SPF record is present (this is "+a/24 +mx"). When there is no SPF record, the extension checks if the sending IP address matches the IP address of the domain itself. If it is the same, the extension reports the email as verified. If you look at the detailed verification status, it will say the sender was "implicitly" allowed.

FAQ: SPF isn't intended to be used on From: addresses!

That doesn't mean the information isn't still useful. If you're a stickler about it, then just pretend the extension is using SenderID. When a domain doesn't publish SenderID records (which is basically always the case), then one may use the SPF record on a domain as if it were a PRA record instead. The vast majority of emails have the same From: and envelope address, and the vast majority of domains have the same SPF and PRA (if present) records, so in practice this really isn't an issue.

Configuration Options

You won't need to set any options when you install the extension, but as you read emails the extension will unobtrusively ask you some questions that will help it verify more emails. (The questions are normally hidden. Hit the plus-sign to see verification details when a verification fails.) These options are also available from Tools | Extensions | Options

These options are for the SPF verification method, which uses the Received: headers of email to establish the identity of the last server to relay the message to you.

Is ___ in your internal network? When emails pass through multiple mail servers within your ISP, the SPF method will be confused as to whether those servers originated the email or are just intermediaries on the email's way to you. When SPF believes it may be confused, it will prompt you with the name of a mail server that it thinks might be a local mail server. If you recognize the name as a part of your ISP or local institution, you may instruct the extension that it is an internal network server. Don't set any IP address as an internal network server if you do not recognize the provided name of the server as belonging to your ISP. The effect of setting this option is to cause the extension to skip Received: headers that match internal network servers.

Is ____ a mail list? Although SPF has trouble verifying forwarded and mail list email, the extension has a work-around. By indicating to the extension which servers are forwarders and mail lists that you subscribe to, the extension can look deeper in the mail headers to recover what mail server sent the email before it arrived at the forwarder/mail list. The effect of setting this option is to cause the extension to look one Received: header deeper only when the envelope domain matches a known forwarder/mail list and when that domain is verified.

DNS Server. You might want to provide the extension with the name or IP address of your local DNS server. Though this setting is auto-detected, non-compliant routers and firewalls on your network may require that you change it. In that case, you may need to adjust the extension's settings in Tools -> Add-ons, and click the Sender Verification Extension's Preferences button. Select a different DNS server, on a non-standard port, such as one that I provide at occams.info:9053.

DomainKeys is a computationally complex verification method, so the extension needs a little bit of help to use DomainKeys. By default, DomainKeys checks are turned off. If you enable DK in Tools -> Add-ons -> Sender Verification Extension Preferences, when you read emails small bits of those emails are sent to my web server which performs the actual verification. The only information sent that might be a potential privacy concern is the IP address of your computer, the IP address of the server where the mail originated, and the From: address in the email. The body of the email is not sent to my server, and no record of the From: address is permanently kept. As soon as I can program the extension to do DK checks another way I will, but it'll be a while before that happens.

Miscellany

Known issues: Mail submitted by the sender to the same server that it's delivered to will not be able to be verified. After switching between Classic, Wide, and Vertical layout, the extension stops working.

I've posted the source for this project above. Use it/copy it however you like. I don't care, but credit would be nice.

Thanks to Paul Johnston for the SHA-1 hash algorithm in JavaScript. I had to modify it to compute the hash incrementally. That might be useful for other projects. The source also contains a module for DNS lookups, including reverse DNS. And there is a module for performing SPF queries.

DOAP file via DOAPSpace, via Freshmeat.