ExchangeDefender is a cloud-based email firewall, and as such we enforce client’s policies against the only email address that is trustworthy: the envelope from address.
Over the past few years there has been a significant increase in use of disposable email addresses (DEA), specifically among mass/bulk mailing operations such as SendGrid, AmazonSES, MailJet, SMTP2Go, SocketLabs, Postmark, Mandrill, Mailgun, MailChimp, ConstantContact, etc. These email addresses, also known as “dark mail” create a unique email address to serve as the official From: line, in an effort to track bounces and delivery problems. Every time you get an email from one of these mass mailing operations the address the message actually came from is unique and generated just for that email/campaign – so whitelisting/blacklisting such addresses can be a challenge for clients that do not use ExchangeDefender’s admin portal or quarantine reports (which detect BATS/DEA addresses and auto-suggest the domain or IP to create a policy).
Bulk mail operations are not just used for mass marketing mail, where companies large and small do not want to build out the infrastructure to deliver tons of email. They are used for notifications, alerts, and most legitimate junk mail that you get. Unfortunately, the same companies are abused in virtually the same way by hackers to deliver spear phishing content. Because the body/header From: address can be easily faked, hackers hide behind places such as SendGrid, AmazonSES. Because they are highly automated, there is relatively little in the way of policing on these networks: after all, they make money to deliver junk mail to you and have little incentive to keep SPAM and phishing content from being sent through their networks.
Over the years, we’ve taught countless MSPs and IT people the difference between the “envelope from” (routing address) and “header or body from” (fake, but friendly looking From address displayed in your email software like Gmail or Outlook). As our client base has changed over the years, we’ve decided to write up an intro-level explanation of the process and how to master it. You can find it here:
We hope you can use it to better block or permit access to these operations. If you’d like our assistance with this process, please open a ticket at https://support.ExchangeDefender.com and remember to attach the .eml file and/or full headers which are required for troubleshooting.
For our pro subscribers, stay tuned. We’ve been hard at work on our antispam engine enhancements and we’ll have a friendlier way to manage this by Thanksgiving 2020.
ExchangeDefender is opening a wider beta test of our whitelisting functionality, which allows IT Solution Providers to whitelist sender mail servers that have broken DNS (missing PTR, mismatched A/PTR records) and poor sender reputation (hosts listed on multiple RBL blacklists).
If you have a sender you would like to whitelist against these essential network tests, please open a ticket at support.ownwebnow.com with subject “Whitelist PTR/RBL: IP Address” and provide as much information in the ticket so we can accommodate this specific request. Only hard non-negotiable rejections to whitelist will be for unknown address space and dialup/consumer cable IP addresses (because due to their nature those are typically dynamically assigned address spaces that shouldn’t be relaying mail at all, they should be using their ISP mail server provided smarthost)
Requests will be reviewed and either approved (and enrolled) or rejected within 24 hours by our CSO.
Background: Inability to previously whitelist broken DNS and dynamic IP address space is rooted in our mission statement. We are here, beyond everything else, to help secure the email. We know our partners, IT Solution Providers, VARs, MSPs, etc do not have the skill set, the time to properly research underlying issues, enough data and statistical models to evaluate sender IP reputation, or even the incentive to discern how big of a security threat and compromise a specific IP address with broken DNS or poor reputation may pose to your client.
In fact, you pay us to worry about those things and keep your clients secure. But, sometimes clients like to think they know better than their technology experts, generally accepted security standards on the Internet, and ExchangeDefender. And the client is always right. But, when they get infected attachments, broadcast storm, password dumps, or other security compromises because they insisted on lowering their security – then ExchangeDefender is on the hook for securing them. And we don’t get to say “told you so” nor do we have any rapid means to fix the issue.
Since my retirement, all of those hard-line policies designed to keep clients safe beyond whatever “specific business case requirement” they may have, are slowly going away. Good news for the client, good news for the partners. Good news for us, because going forward we will start providing Email Security Engineering services – so when you get a security compromise or an usual issue and you’ve asked us to compromise your security – we will be able to address the issue on your behalf.
I choose to look at this as a positive – we will help our clients meet their business needs and get the mail they desperately need – and if something breaks we will be there to help assist with the cleanup (for a fee, of course). This, among many other service related things, is just the part of the ExchangeDefender being more responsive and service oriented when it comes to our clients demands as opposed to our expert opinion as a security policy.