Protect Yourself From Phishing

This is an extension for the Mozilla Thunderbird email program 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 an anti-phishing tool to protect you from fradulent emails asking for your sensitive information, and zombie-spread viruses claiming to be from someone they are not. The extension uses Sender Policy Framework (SPF) (in a nonstandard way) 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, 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.

Latest Version

The current version of the extension is 0.9.0.5, posted December 10, 2009. This is the first attempt at compatibility with Thunderbird 3. I am no longer actively developing this extension but I try to keep it going as time permits. To 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 > Install... and install the file you downloaded.

Previously you could also get the extension from Mozilla Add-ons, but for reasons that are not important I will not be posting updates there anymore. It has the lastest version compatible with Thunderbird 2.

Screen Shots

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

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) 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, 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 Google's Public DNS service, 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 (host:port format is supported).

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.