Thoughts on filters

One of the questions we received during the EEC16 closing keynote panel was why isn’t there a single blocklist that everyone uses and why don’t ISPs share data more. It would be so much easier for senders if every ISP handled mail the same as every other. But the world isn’t that simple, and it’s not always clear which mail stream is spam and which is good mail.

12495088_10154028658527410_7653293570464523506_n

There were quite a few answers but they basically boiled down to a few facts.

  • Different blocklists have different data strengths and weaknesses.
  • No blocklist has all a full view of all the bad mail.
  • You may want to have different polices for delisting depending on what kind of mail the blocklist is targeting. For instance, Spamhaus has different polices for different lists: CBL has self serve delisting, SBL requires email, ROSKO requires no traceable spam for 6 months.

The short reason was we use different lists and techniques because it makes the spam filtering better.

When I got home from the conference, I saw In-depth analysis of the lessons we learned while protecting Gmail users post. Among other things, it answered the “why not one blocklist” question. Even more, I think it did a really good job of talking about what email looks like from the receiving end.

Any defense can be defeated – Use defense in depth with multiple layers of protection.
Since no combination of detection systems at a given layer is perfect, there is a need to add multiple layers of defense to make it even harder for attackers.

One thing I’ve been trying to get across to marketers is that email is an a very malicious channel. Many of the bad mails out there, the ones the filters are aiming for, are dangerous and malicious. Those attackers spend a lot of time trying to figure out how to get past the defenses.

Make it hard for attackers to understand your defenses – Use overwhelming force and deploy many countermeasures at once.

It is very important to make probing more difficult for attackers by rolling out multiple changes. That way they are overwhelmed by the number of things to test and can’t easily figure out what changed.

This is why it’s so hard to test “what Gmail changed.” They are going out of their way to release multiple things at once. It’s also why it’s not really useful to test. It’s more useful to look at your mailing practices and see where they might be borderline and driving your reputation down.

The whole article is well worth a read. It gives a good overview of what Gmail is doing and how they think about email, filtering and dangers. It also gives examples of the different challenges they deal with on a regular basis.

Overall, it’s important to realize that filters are an important part of the email ecosystem. They are a big part of why it’s a viable marketing channel. Think of it this way, an unweeded garden is not as productive as a weeded garden. Weeds take nutrients away from the plants and stunt their growth. They also make it harder to find the actual produce at harvest time. Filters are the herbicides and weeding that keep gardens healthy and productive. Without them, no one could effectively use or trust email.

Related Posts

Prepping for EEC


Tomorrow I head off to New Orleans to the EEC conference. It’s my first one and I’m really looking forward to meeting some of the people I only know online.
I’ll be speaking on two panels on Friday:
All You Ever Wanted to Know about Deliverability (But Were Afraid to Ask) at 10:50. This is your chance to ask those questions of myself and other experts in the field. I always enjoy Q&A panels and actually hearing from folks what their big deliverability questions are. (and remember, if you have a question, you can always send one to me for Ask Laura)
and the closing Keynote panel
ISP Postmasters & Blacklist Operators: Defending Consumer Inboxes at 1:10. I’m on a panel with various ISP postmasters, blacklist operators and we’ll be talking about what it’s like dealing with the deluge of mail. For instance, there is a huge outbreak of bot-spam at the moment, and a lot of the filters are struggling to keep up. In fact, I’m a last minute replacement for one filter company as they are in all-hands-on-deck firefighting mode to keep their customers safe.
Hope to see you there!
 

Read More

Random thoughts on reporting abuse

stop_atOn IRC today, someone mentioned an Ars Technica article discussing how a research team tried to contact Xfinity about a security flaw in their home security system.

Read More

Security vendors and trust.

A big part of my predictions for 2016, that I’ll publish shortly, is that security is going to be a huge issue. I think we’re really going to see receivers expecting senders to have their houses in order when it comes to sending mail.
Of course, some filter companies need to get their houses in order to. Yesterday, a security researcher went public with problems in the TrendMicro anti-virus appliance. These vulnerabilities would let any email sender remotely execute code on the recipients machine with no interaction of the user. They also exposed all the passwords on the machine to the outside world.
Even worse, Trend doesn’t seem to understand the urgency to fix this. They have started releasing patches for the exploits, but there are significant problems with the patched versions as well.
If you’re a Trend user, you may want to consider other vendors for desktop security. I know that no security is perfect and that other vendors have problems, too. But shipping a password manager that exposes all passwords is just incompetence. It seems like a corporate lack of understanding of what their business is and how to actually create security software.
Even worse is that lack of urgency from the Trend folks as the security researchers are explaining the problem. I don’t care if the person receiving the report was the janitor, anything that says security exploit should be escalated to someone who can determine if the report is valid.
Compare Trend’s reaction to this to Juniper’s reaction to discovering a backdoor in their code in December. First off, Juniper found the exploit during a routine code review. That alone tells you Juiper is continually monitoring their code security. Second, Juniper was reasonably open about the issue, with executives posting blogs and security posting advisories talking about the issue. More importantly, they shared how they were going to fix it and prevent it from happening again.
Security is such a large issue right now. We have to be able to trust our vendors to do what they’re selling us. Every vendor is going to make mistakes and have vulnerabilities. No code and no developer is perfect. I do expect, though, that vendors will take exploits seriously and act fast in order to correct the problem. I’m not seeing that sense of urgency with Trend.
 

Read More