A while back, I realized that Reply-To sometimes have significant information and I was not filtering on it. The issue came to a head when we received a message with these characteristics:
Of course, the message also passed SPF/DKIM/DMARC based on Webex.com, but the message was fraudulent. This address appears to normally be used for Webex meeting invites. Blocking the address or the domain was not an option. The only way to block the fraudulent message was to filter on the Reply-To address. But how should the new filtering policies be designed?
If the Reply-To address is aligned with the From address or the Mail From address, its reputation is already being checked. So I only check a Reply-To address when it is in different organization than the other two organizations (using the DMARC public-suffix-list to define "same organization").
These filtering strategies may be needed:
- The message is whitelisted or blacklisted. The Reply-To address is not evaluated.
- The Reply-To address is blacklisted, so the message is blacklisted and the From address is ignored.
- The From address is verified and is trusted with any Reply-To address. Document approval requests from Docusign.net or Adobesign.com are examples. The Reply-To address is ignored.
- The From address is verified and Reply-To address may be acceptable or unacceptable. For recognized senders, the combination of verified From address and Reply-To address determines the disposition.
- When the From address by itself is ambiguous because of good and bad clients, unrecognized Reply-To addresses for that From address are sent to quarantine.
After analyzing my data, I found many reasons why the Reply-To organization may be different from the other addresses:
- The From address is a domain that can be discarded if that name gets blacklisted by the RBLs, and the Reply-To address indicates the parent company. One example was: From=dollargeneralmarketing.com, Reply-To=dollargeneral.com.
- The From address and the Mail From address indicate an email service provider because the client cannot provide a DKIM private key for From authentication. The client address is hidden in the Reply-To. Otter.ai and Read.ai use this approach.
- The From address indicates the client, but an email service provider will handle replies. The Reply-To address indicates that service.
- The From address indicates a corporate subsidiary or product name that will be recognized by the recipient, but the Reply-To address is the parent company.
- An infrastructure provider hides the client address in the Reply-To field, and a spammer uses the service to send malicious traffic with partial anonymity. This is what happened in my messenger@webex.com example.
- A spammer uses multiple made-up domains for the From address, but a consistent domain for the Reply-To. Putting a block on the Reply-To address helps to block future attacks.
Additionally, we use a customized External Sender warning that notifies the user when the Reply-To field is inconsistent with the From address. This provides a little extra protection for imperfections in our Reply-To filtering data.
I had to write new code for our custom filtering software to manage this risk. Does anyone have a product that implements this type of protection out-of-the-box?