This blog article is an addition to the previous blogs about external warning messages based on requests I have received and feature and filters we have deployed in production to help our users to make the right decisions.
Every email admin and some end user most likely have seen one way or another of tagging external emails. While this sound like a very easy task there are some pitfalls to avoid. The biggest challenge is that with 'tagging' being more and more common end-users tend to no-longer or at least tend to more often ignore such messages as they come up far too often. The goal of this blog posting is to detect messages where the "reply-to" and "sentby" addresses are not matching the "from" address of a message and to display simple warning messages to alert the users. I will demonstrate in this blog the individual components and building blocks required to make such a solution work and will give you some possible examples of what can be done.
An overarching goal is to warn users when a warning is required but to just tag messages in the subject line for some consistency.
Such an example would then look like :
So what components are required to make this solution work:
a) disclaimer template to display the red bar and the included text
b) an understanding of the 4 key email fields , FROM, ENVFROM, REPLY-TO, SENTBY
c) one or more content / message filters to compare headers and display the disclaimer.
Lets start with the disclaimer, similar to the one I have previously shared in my blog with just a different back ground color.
Step 1:
Go into Mail Policies \ Text Resources and create a new text resource. Fill out the filed as displayed below.
For easier copying the HTML text used, make sure you select the <> icon before copying :
<div id="demo"><br>
<table style="width: 100%; border-collapse: collapse; border-style: double; background-color: lightpink;" border="0">
<tbody>
<tr>
<td style="width: 92.1054%;"><strong>Caution</strong>: This email originated from outside the organization. The reply-to address does not match the sending address so special care is required should you not recognize the sender. </td>
</tr>
</tbody>
</table></div>
In order to avoid formatting issues with some HTML messages, make sure to add maybe one empty line on top of the HTML and text only code. The resulting form in HTML edit mode should look like the following:
Save the text resource. The next step would be to create similar text resources for two additional use cases. Just pick different describing names as below and update the text/HTML accordingly.
In our example we created External_Warning_Sender and External_Warning_ReplyToandSender and updated the text accordingly as shown below:
and the second one:
This completes the creation of the required basic disclaimers.
Step 2:
The next steps is to best understand the content of the 4 messaging fields. While you still have the option to check the message header in your email client of choice I recommend a slightly better approach to extend the Ironport mail_logs by adding a debug line for easier troubleshooting of this feature.
Create a message filter like the below :
CLIExtendedFieldsDebugv1: if recv-listener == "InboundInterface" {
log-entry("DEBUG KEY FIELDS MessageID=$Header['Message-ID'] FROM=$Header['From'] ENVFROM=$EnvelopeFrom REPLYTO=$Header['Reply-To'] SENTBY=$Header['Sender']");
}
The exact steps on how to add a message filter to an ESA have been described in my previous blog about headers. Those 4 lines will be replaced in the mail_logs with details about message headers like in the following example:
Thu Oct 8 08:38:52 2020 Info: MID 49870619 Custom Log Entry: DEBUG KEY FIELDS MessageID=<202008101219.11ruj23t0d5zj@bo.d.mailin.fr> FROM=Make Safety Visible.com <help@makesafetyvisible.com> ENVFROM=bounces-11ruj23t0d5zj-lawrence.park=fmc-na.com@bo.d.mailin.fr REPLYTO=richardnichols@sgworldusa.com SENTBY=richardnicholsmailer@sgworldusa.com
This also you to have a better understanding of what key fields you will see within your headers.
Step 3:
The last steps is to create the corresponding content or messages filters. To get you all started quickly i will create a prototype using the GUI but you can then easily combine them all into one message filter on CLI once you are happy with the results. There are endless possibilities and I will show a few examples below:
The first example displays a warning message if the reply-to and env from address are not matching and this is by far the most important use case. This technique is used very often in BEC messages and giving at least an alert to end users or VIP's might help with some damage. Simply replace the xxxxxx.yyyyyyy@domain.com with your email address and test it out. Once happy with the results remove that line and apply the content filter to your default or any other relevant policy.
The second example displays a warning message if the sentby and env from addresses are not matching. While i think this is also important you will see with the debug of the key fields that the sentby is mainly used in either delegation mode, application emails or by list servers. Unfortunately also attackers have found this option so i would still recommend using it in production. Again here just replace the xxxxxx.yyyyyyy@domain.com with your email address and test it out. Once happy with the results remove that line and apply the content filter to your default or any other relevant policy.
The third example shows a combination of both checks into one and stretches the possibilities of what can be done in a GUI based filter.
To help a little with understanding the logic the following steps will need be performed:
a) apply the filter if the message recipient is a defined user or domain, for easy testing
b) check for the presence of the reply-to field (header("reply-to")
c) check for the presence of the sentby filed (header("sentby")
d) check if the reply-to field matches the envelope from field
e) check if the sentby field matches the envelope from field
f) display the combined disclaimer (add-heading)
g) set an SMTP x-header for further processing and detection (insert-header)
h) optional save a copy of those messages in a quarantine queue for later analysis (duplicate-quarantine)
Once you activate the content filter in your policy of choice you can test out if it does what you wanted it to do. There are now multiple options where you can enhance the filter(s) from here.
a) compare the reply-to and sentby field to the FROM field instead of the envelope from
b) display some detailed information on headers to end users about what they should be aware off.
Your imagination will stop how far you can go but keep in mind, displaying a warning message for every incoming message is no longer recommended practice. Enable your end users to make smart email decisions by giving them the tools required to be informed.
Our next blog articles will demonstrate new ways how you can help your end users and how to make Ironport / Agari and O365 work even better together.
Happy reading and feel free to suggest any new topics or provide a comment.
Comments