There's one area where I've always thought Thunderbird should be a cross platform leader and example to everyone: setting Email Client Standards.
I spent a lot of time in the anti-phishing/anti-fraud world. During a stint at dmarcian I wrote up an entire proposal that I titled A.P.E.C.S. - Anti-Phishing Email Client Standards. I should probably publish this document at some point since it looks like they've since taken it down and IMO, it still needs to happen.
When you dive hard into the email security problem you quickly discover that there are layers to how end users are exploited.
- Sending Mail Servers
- Receiving Mail Servers
- Information presented to users in the mail client
- Links and attachments in the emails themselves
- The phishing sites they link to
Each layer of this process needs to be addressed. DMARC let's sending mail servers verify that they are actually allowed to send email on behalf of the domain. That alone is a huge scope of the problem and puts the domain owner in charge of preventing abuse from their own domain.
Receiving mail servers have a number of factors that they use to verify inbound emails and DMARC makes that process a lot easier, but you still have to have spam filters, virus scans, IP and sender reputation management, reverse DNS lookups. The tools supporting users here are always getting better but they won't ever be perfect.
The mail client itself is critical though. We know the filters aren't perfect and typically have to err on the side of deliverability, which means that users are going to see messages that the mail server thought were questionable. You're already seeing warning messages in Google for things like this, but the factors here can absolutely be standardized around a number of factors. Users don't respond to "you can trust this" indicators (studies show, don't have them handy) but they do respond to warnings as long as the warnings are very targeted and rare. If you get a warning about every message, it's going to get ignored.
Links and attachments are also in the mail client scope. Attachment scans and link reputation absolutely need to be a part of the scope of this problem. There's an opportunity for link trust to be standardized in the same way as dmarc. Does the URL match the DMARC sender? Cool, that's a really good sign. Is the URL going through a shortener or other tracking system? In that case, there's probably a lot more risk involved. In order to bypass filters, shorteners will link to something safe and then change the redirect target after successful delivery. Reputation scores need to be tracked on shorteners based on immutability of links and responsiveness to abuse take downs. If they don't, then those services should generate a giant warning in the email client and potentially even have the link disabled in the message.
Phishing sites themselves are all over the place and working with hosting abuse teams to take them down is a gargantuan task. Working with a shortener who's linking to it to take it down would prevent every recipient of the message from being duped.
That's the high level. The standards are needed and should be applied across every email client vendor, from Thunderbird to Gmail to Outlook/365 to Fastmail to Apple. IMO Thunderbird has an opportunity to lead the charge here and become a force that protects people from phishing at the point of consumption, regardless of the rules on the mail server itself.
> I should probably publish this document at some point
I'd be interested in seeing it. It sounds like a pretty good idea. It's incredible to me how effective even the worst phishing email/sites are and to me that's an indication that not enough is being done to point out clear warning signs to users.
> Phishing sites themselves are all over the place and working with hosting abuse teams to take them down is a gargantuan task. Working with a shortener who's linking to it to take it down would prevent every recipient of the message from being duped.
The URL shorteners can be the worst. They don't seem to care who creates a link to something, and don't do even basic checking of whats at the other end. You'd think a person creating a link to yet another URL shortener would set off major flags, but they don't seem to care.
Same with survey/form sites that keep being hijacked for phishing purposes. They don't bother with even basic checking for scams either. If someone creates a form with a password field that'd be easy to flag for review, but it doesn't happen. I can report a bunch of identical phishing sites that were created with URLs like:
random_form_builder_site.com/targetcompanyname001
random_form_builder_site.com/targetcompanyname002
random_form_builder_site.com/targetcompanyname003
and while they'll generally take them down, they'll do nothing to prevent:
random_form_builder_site.com/targetcompanyname004
random_form_builder_site.com/targetcompanyname005
random_form_builder_site.com/targetcompanyname006
from being created. Not checking for targetcompanyname in the url of new forms/surveys, and not bothering to check to see if the 12 new sites someone just created are identical to the last 12 they were asked to disable.
Anything that can be done to help make those sites less attractive to users before they even click the link in the email they got would really help.
I spent a lot of time in the anti-phishing/anti-fraud world. During a stint at dmarcian I wrote up an entire proposal that I titled A.P.E.C.S. - Anti-Phishing Email Client Standards. I should probably publish this document at some point since it looks like they've since taken it down and IMO, it still needs to happen.
When you dive hard into the email security problem you quickly discover that there are layers to how end users are exploited.
- Sending Mail Servers
- Receiving Mail Servers
- Information presented to users in the mail client
- Links and attachments in the emails themselves
- The phishing sites they link to
Each layer of this process needs to be addressed. DMARC let's sending mail servers verify that they are actually allowed to send email on behalf of the domain. That alone is a huge scope of the problem and puts the domain owner in charge of preventing abuse from their own domain.
Receiving mail servers have a number of factors that they use to verify inbound emails and DMARC makes that process a lot easier, but you still have to have spam filters, virus scans, IP and sender reputation management, reverse DNS lookups. The tools supporting users here are always getting better but they won't ever be perfect.
The mail client itself is critical though. We know the filters aren't perfect and typically have to err on the side of deliverability, which means that users are going to see messages that the mail server thought were questionable. You're already seeing warning messages in Google for things like this, but the factors here can absolutely be standardized around a number of factors. Users don't respond to "you can trust this" indicators (studies show, don't have them handy) but they do respond to warnings as long as the warnings are very targeted and rare. If you get a warning about every message, it's going to get ignored.
Links and attachments are also in the mail client scope. Attachment scans and link reputation absolutely need to be a part of the scope of this problem. There's an opportunity for link trust to be standardized in the same way as dmarc. Does the URL match the DMARC sender? Cool, that's a really good sign. Is the URL going through a shortener or other tracking system? In that case, there's probably a lot more risk involved. In order to bypass filters, shorteners will link to something safe and then change the redirect target after successful delivery. Reputation scores need to be tracked on shorteners based on immutability of links and responsiveness to abuse take downs. If they don't, then those services should generate a giant warning in the email client and potentially even have the link disabled in the message.
Phishing sites themselves are all over the place and working with hosting abuse teams to take them down is a gargantuan task. Working with a shortener who's linking to it to take it down would prevent every recipient of the message from being duped.
That's the high level. The standards are needed and should be applied across every email client vendor, from Thunderbird to Gmail to Outlook/365 to Fastmail to Apple. IMO Thunderbird has an opportunity to lead the charge here and become a force that protects people from phishing at the point of consumption, regardless of the rules on the mail server itself.