Who are mimecast?

Mimecast is a filter primarily used by businesses. They’re fairly widely used. In some of the data analysis I’ve done for clients, they’re a top 10 or top 20 filter.
Earlier today someone asked on Facebook if mimecast may be blocking emails based on the TLD. The short answer is it’s unlikely. I’ve not seen huge issues with them blocking based on TLD of the domain. They’re generally more selective than that.

The good news is mimecast is really pretty good about giving you explanations for why they’re blocking. They’ll even tell you if it’s mimecast related or if it’s a specific user / user-company block.
Some example rejection messages from a recent dive into some bounce logs.

  • Administrative prohibition – envelope blocked – https://community.mimecast.com/docs/DOC-1369#
  • Email rejected due to security policies – https://community.mimecast.com/docs/DOC-1369#
  • Envelope blocked – User Entry – https://community.mimecast.com/docs/DOC-1369#550
  • Invalid Recipient – https://community.mimecast.com/docs/DOC-1369#
  • Message expired -> Open relay not allowed – https://community.mimecast.com/docs/DOC-1369#451
  • Rejected by header based Blocked Senders: address@example.com – https://community.mimecast.com/docs/DOC-1369#
  • Rejected by header based manually Blocked Senders: address@example.com – https://community.mimecast.com/docs/DOC-1369#
  • Remote server returned message denied by administrative policy -> Administrative prohibition – envelope blocked – https://community.mimecast.com/docs/DOC-1369#550
  • spamcop.mimecast.org Blocked – see http://www.spamcop.net/bl.shtml?10.10.10.10. – https://community.mimecast.com/docs/DOC-1369#550

If you look at the page linked to you can see that there is a huge amount of flexibility in how and who can block mail using mimecast. Mimecast itself can push filters, local administrators can filter mail for the particular domain they manage, and individual users can set up filters. And, users seem to take advantage of that.
Dealing with a mimecast block involves figuring out who is responsible for the block. Luckily, the mimecast rejection messages and documentation give clues as to whether it’s the local administrator configuring the policy or if it’s the end user. In most cases it’s not actually mimecast blocking the mail.
Mimecast provides tools and an interface to manage incoming mail, but does not actually push out rules like many of the other appliances. That’s good and that’s bad. It’s good because you don’t have a 3rd party making delivery rules for different businesses. It’s bad because once a company administrator gets to the point of blocking specific mail it’s going to be very difficult to convince them to lift that block.
Why? Remember the discussion about productive mail?
Productive Mail: Mail that furthers a business’ goals and supports their underlying business model. Mail can be both solicited and wanted by specific endusers. But, a particular company can decide to block mail simply because they don’t see the mail as beneficial to the overall business. Thus the mail is blocked for being unproductive.
We can assume that employees who have access to create mail blocks in mimecast, and other business filters, have the authority to do so. Which means when you’re looking to get unblocked through mimecast, you’re likely having to convince the very person who blocked you to unblock you.
These types of blocks are distinctly different than negotiating with a consumer ISP or even a filtering company. There is no appealing to engagement or appealing to solicited. The business doesn’t really care about either, all they care about is their employees are working while they’re at work and using corporate resources.

Related Posts

What kind of mail do filters target?

All to often we think of filters as a linear scale. There’s blocking on one end, and there’s an inbox on the other. Every email falls somewhere on that line.
Makes sense, right? Bad mail is blocked, good mail goes to the inbox. The bulk folder exists for mail that’s not bad enough to block, but isn’t good enough to go to the inbox.
Once we get to that model, we can think of filters as just different tolerances for what is bad and good. Using the same model, we can see aggressive filters block more mail and send more mail to bulk, while letting less into the inbox. There are also permissive filters that block very little mail and send most mail to the inbox.
That’s a somewhat useful model, but it doesn’t really capture the full complexity of filters. There isn’t just good mail and bad mail. Mail isn’t simply solicited or unsolicited. Filters take into account any number of factors before deciding what to do with mail.

Read More

AHBL Wildcards the Internet

AHBL (Abusive Host Blocking List) is a DNSBL (Domain Name Service Blacklist) that has been available since 2003 and is used by administrators to crowd-source spam sources, open proxies, and open relays.  By collecting the data into a single list, an email system can check this blacklist to determine if a message should be accepted or rejected. AHBL is managed by The Summit Open Source Development Group and they have decided after 11 years they no longer wish to maintain the blacklist.
A DNSBL works like this, a mail server checks the sender’s IP address of every inbound email against a blacklist and the blacklist responses with either, yes that IP address is on the blacklist or no I did not find that IP address on the list.  If an IP address is found on the list, the email administrator, based on the policies setup on their server, can take a number of actions such as rejecting the message, quarantining the message, or increasing the spam score of the email.
The administrators of AHBL have chosen to list the world as their shutdown strategy. The DNSBL now answers ‘yes’ to every query. The theory behind this strategy is that users of the list will discover that their mail is all being blocked and stop querying the list causing this. In principle, this should work. But in practice it really does not because many people querying lists are not doing it as part of a pass/fail delivery system. Many lists are queried as part of a scoring system.
Maintaining a DNSBL is a lot of work and after years of providing a valuable service, you are thanked with the difficulties with decommissioning the list.  Popular DNSBLs like the AHBL list are used by thousands of administrators and it is a tough task to get them to all stop using the list.  RFC6471 has a number of recommendations such as increasing the delay in how long it takes to respond to a query but this does not stop people from using the list.  You could change the page responding to the site to advise people the list is no longer valid, but unlike when you surf the web and come across a 404 page, a computer does not mind checking the same 404 page over and over.
Many mailservers, particularly those only serving a small number of users, are running spam filters in fire-and-forget mode, unmaintained, unmonitored, and seldom upgraded until the hardware they are running on dies and is replaced. Unless they do proper liveness detection on the blacklists they are using (and they basically never do) they will keep querying a list forever, unless it breaks something so spectacularly that the admin notices it.
So spread the word,

Read More

April 2016: The Month in Email

We are finishing up another busy month at WttW. April was a little nutty with network glitches, server crashes, cat woes, and other disruptions, but hopefully that’s all behind us as we head into May. I’ll be very busy in May as well, speaking at Salesforce Connections in Atlanta and the Email Innovation Summit in Las Vegas. Please come say hello if you’re attending either of these great events.
April2016MiE
Speaking of great events, I participated in two panels at EEC16 last month. We had a lot of great audience participation, and I met many wonderful colleagues. I wrote up some more thoughts about the conference here. I also had a nice conversation with the folks over at Podbox, and they’ve posted my interview on their site.
In the Podbox interview, as always, I talked about sending mail people want to receive. It always makes me roll my eyes a bit when I see articles with titles like “5 Simple Ways to Reach the Inbox”, so I wrote a bit about that here. In addition to sending mail people want to receive, senders need to make sure they are collecting addresses and building lists in thoughtful and sustainable ways. For more on this topic, check out my post on list brokers and purchased lists.
These same not-so-simple tricks came up again in my discussion of Gmail filters. Everyone wants a magic formula to reach the inbox, and — sorry to burst your bubble — there isn’t ever going to be one. And this is for a good reason: a healthy filter ecosystem helps protect all of us from malicious senders and criminal activity. The email channel is particularly vulnerable to fraud and theft. The constant evolution of filters is one way mail providers can help protect both senders and recipients — but it can be challenging for senders and systems administrators to keep up with this constant evolution. For example, companies sometimes even inadvertently filter their own mail!
I also wrote a bit about how B2B spam is different from B2C spam, and how marketers can better comply with CAN SPAM guidelines in order to reach the inbox. We also republished our much-missed friend and colleague J.D. Falk’s DKIM Primer, which is extremely useful information that was at a no-longer-active link.
One of my favorite posts this month was about “dueling data”, and how to interpret seemingly different findings around email engagement. We also got some good questions for my “Ask Laura” column, where we cover general topics on email delivery. This month we looked at “no auth/no entry” and the Microsoft Smartscreen filter, both of which are useful things to understand for optimizing delivery.
Finally, we are pleased to announce that we’ve joined the i2Coalition, an organization of internet infrastructure providers. They posted a nice introduction on their blog, and we look forward to working with them to help advocate and protect these important technical infrastructures.

Read More