Caution message for incoming mail outside the domain
Idea shared by Fred Verna - 3/11/2021 at 8:23 AM
How about the ability to add something like this to body of the email coming from outside the Domain.

It seems this is going to a requirement from any Cyber Insurance companies.

19 Replies

Reply to Thread
Robert Emmett Replied
Employee Post

While the following solution does not put a banner or inject the caution into the message body, you can configure a domain-level content filter to prepend [EXTERNAL] or some other text in the subject line.

1. Create a new domain-level content filter
2. Enter name, for example, External Email
3. Set Match Type to ALL conditions must be met
4. Add a new condition with the following settings:
   - Condition Type -> From Address
   - Field -> From specific domains
   - Comparison -> Does Not Match
   - From specific domains -> yourdomain.com
5. Add an action with the following settings:
   - Action -> Add Text to Subject
   - Text to Add -> [EXTERNAL] or [CAUTION], etc.
Robert Emmett
Software Developer
SmarterTools Inc.
(877) 357-6278
Already tried this and it causes more confusion to the end user. The banner is the best solution.
It appears that this request was at least partially implemented in build 7719.   After upgrading recently to this build, I noticed that a message from VMWare appeared with this banner:

    This message contains content from external sources.

The banner is highlighted with a pale yellow background, and it appears between the "To:" address and the [Message] tab, so it is not part of the message itself.   However, I have messages from multiple external sources, and this is the only one that triggered the banner.

One benefit of this approach is that it is apparently not based on altering the message, so it presumably will not break DKIM signatures.    By comparison, the suggestion to add text to the subject or body will break DKIM signatures.

Can someone from SmarterTools clarify how this feature works -- what message characteristics cause it to be displayed, whether the message can be disabled and re-enabled by the system manager, and whether the system manager can control the specific wording used?

This type of tagging has become popular because many email clients have chosen to hide the FROM address from the user, a move that is unfortunate, risky, and unjustified.  SmarterMail used to do this also; now it only hides the FROM address some of the time.  I wish it was never.   (Hovering over the Friendly Name will always display the address.)

There is a lively debate about how much "Trust indicators" like this can actually affect user behavior.   This is the only journal article that I have found on the subject, but would be interested in what others can find.

We use the [EXTERNAL] subject message as we have no choice - this has reduced the no. of times users fall for spoofed phishing messages so it was beneficial. But a banner would indeed be more professional.

A banner with the ability to turn on/off is my vote!  Thanks for listening.
We would definitely use that.
The domain level content filter also seems to have another unwanted side-effect: user-level content filters randomly do not work. This started about the time we implemented the domain level content filter to prepend [EXTERNAL] to message subject.
But the banner will only appear in webmail.   Cell phone and email client are missed.   Content change appears everywhere.
+1 to insert customizable banner to message. 
We are now hearing about the insurance company requirement from clients.  The insurers want a number of things, including 2FA, that seems pretty consistent.  Some are also wanting the banner added within the body so it is not e-mail client  specific.  It looks like it would be necessary to move to another mail platform if its not possible to comply so if this is increasing and on the horizon it would be good to get ST thoughts on it.  It might be possible to do it outside SM, maybe in Declude or as some other function in a vectored chain.
SmarterMail(tm) 17
MAPI over HTTP - Let's flesh it out with Exchange like features!
We have this requirement from a business we host, we have a proc monitoring app that we built a while back that does tons of various items, including this.
Looking into this a little further I see there is a new MAPI property called IsExternalSender and that Microsoft Clients are being updated to use to  insert the external sender warning.  There is some preliminary information here: Native external sender callouts on email in Outlook - Microsoft Tech Community 

Using a property within the received email and having the email client insert the warning might be preferable to altering the body of the email.  It seems likely that, with the property available, other email clients would follow.

ST, could you look at this property  and perhaps add some simple functionality that can be enabled to set the property?  Ideally, if insertion can be enabled or disabled at the client, this could be enabled server wide and would not need domain and user override options.  The user would be responsible for enabling it or disabling it within their client - Outlook for starters.

SmarterMail(tm) 17
MAPI over HTTP - Let's flesh it out with Exchange like features!
Declude has the ability to add content to subject, body header, or body footer.   Because Declude has multiple-attribute rules, you can have different content in different positions for different clients.   Best of all it is available today, so you don't need to lose business over this feature.   I recommend implementing Declude with SmarterMail configured as an incoming gateway.

The MAPI idea is an interesting one, but as was mentioned earlier in this chain, organizations that want this feature will want certainty that it appears in Outlook, WebMail, and Cell Phone.    The only way to do this today is to modify the message.   Presumably, organizations that want this capability will not use auto-forwarding, so broken DKIM signatures should not be a problem.
Yes, we use Declude and I agree that it could be implemented there and would, in my experience, be very robust.  I also agree that it, or something like it, might be the only way to ensure broad coverage if one wanted to do it today.   There is another consideration though.  As insurers look for this functionality I suspect that we might also expect that we'd see their legal department war chests come into play when something goes wrong.  I'd sure prefer to have the functionality present in the email client and administered by the end user than to be seen to have been charging for, or bundling in, functionality that someone claimed failed.  I'm sure we could log it and put up a reasonable defense but the best situation would be not to be named in the first place.

If we could have a client respond to the insurer or tick the the box that the mail server implements industry standard functionality via the MAPI property so the user can enable the functionality using popular email clients 'such as Microsoft Outlook' we might get though it.  These look like early days.  I will do a little tinkering in Declude in the interim.

If we go back to the idea that it is something ST should implement, I'd hope that it would be the responsibility of the user and/or domain administrator to enable and monitor.

As an afterthought, I wonder whether Mails Best Friend might want to take it on with some extra features as a paid add-on within Declude Reboot.
SmarterMail(tm) 17
MAPI over HTTP - Let's flesh it out with Exchange like features!
Declude has issues though, it's old (very old), it doesnt seem like it is supported anymore and isnt going anywhere (vaporware now), relies on the old XML stuff that SM 17 no longer has, so you have to rely on external scripts to do conversions for you.

We had issues with stability and Declude stalling out or consuming massive amounts of CPU resources.

I wouldnt hold my breath on Declude Reboot...
About Declude:  
I have customized Declude heavily, including integrating it with SQL to avoid performance problems and to work around a couple of bugs that I found.   Unlike some of its bad press, Declude has been very stable for me over several releases of SmarterMail.  Please understand that I wanted to buy a commercial product, but I kept finding vendors that did not understand the email security problem.    I kept asking this question, and did not hear acceptable answers until I found Declude:  

"Example.com has moved to outlook.com but has not updated their SPF policy.   How do I configure an override that allows me to leave SPF enabled and does not enable spoofing of Example.com or Outlook.com". 

To Proto's idea:

I have no objection, but I do not see us getting from here to there.

First, there is a trust problem.   External origination is determined at the network perimeter, by the incoming gateway.   In his model, banner generation is triggered by the email server and implemented by the email client.  It is difficult for the email server to know with certainty that the message originated externally.   The Authentication-Results header is the current effort to solve this problem, so it is possible, although the identity verification system is rudimentary.

You need an email filter that creates the A-R record, and a mail store that parses it.   Both need to be configured with a secret code to distinguish between internally-generated and externally-generated versions of the header.   Realize that the code is not really a secret because it appears as plaintext in every message header.  So the email filter needs to strip any incoming A-R header which uses the internally-assigned secret code, and the code probably needs to be changed occasionally.  This solution is probably doable if you use an Linux-origin product like Postfix for both roles, but I have not seen much evidence that the commercial market is moving in that direction.
Secondly, there is the Microsoft-proprietary problem.  MAPI and Outlook are Microsoft-proprietary, and I am alarmed by the direction they seem to be moving with the technology.  A real standard would need to address all user interfaces, and support multiple communication protocols between email client and email server, which MAPI does not.    However, I have to grant that your linked article indicates that Microsoft has an interesting story for those who are willing to commit further to the Microsoft vortex.   I am heading the other way right now.

An aside:  One could fantasize that IETF will address this, but they will not.   They do not consider communication between email clients and email servers to be an interoperability issue, and they do not expect any developers to listen even if IETF tries to tell them how email clients should behave.

Finally, you have to consider whether a standardized message is really what you want.   I think your clients will have differing opinions about what the banner should say and how it should be presented.  Additionally, their opinions will change over time in response to perceived threats.    (I already find myself wishing that I had control over the webmail banner that SmarterTools has added.)  After all, a standardized banner becomes easy to ignore, which will defeat the goal for which the banner was created..

Sorry, but I cannot find a winning path here.  I wish there was.
I tried to implement Robert's [External] marking at the domain level. That appears to work well. My problem it broke my individual content filtering. I move a lot of unnecessary to other folders to view later cleaning up my mailbox.

Created a ticket and had learned once a domain level rule has been applied user specified will not run.

Can anyone at SmarterTools explain this in more detail, unless I misunderstood what the tech wrote? Why would filtering stop at the domain level?
To Douglas Foster's comment.  I agree on Declude although we have not modified it to the extent you have.
I agree on the preferences and changing message and other comments including desensitizing to a standard message and certainly to what is in the subject line.

The problem that may be staring us down is the insurance requirement as this becomes more common.

The 2FA we have available at the moment was enough to get the box checked successfully for clients.

Perhaps the best we could hope to do on the external notification would be a banner like Fred Varna proposed back in March and either enable or disable it by domain (user level ???) so that the client can check off that box for insurance companies that require it.  The subject line doesn't seem to be enough.

Absent that, it is just another compelling reason to need to abandon SM in search of another (quite possibly inferior) solution that can provide it.  Most companies are not going to ignore this once the insurer has drawn their attention to it, nor are they going to be able to wait for a possible up-vote on something that addresses it and wait several months for implementation.

I have mixed feelings about altering the content of an inbound email to insert the banner so that it is there in email clients as well as in the web interface but it is clear the Insurers aren't worried about it and it would be something the client would need to enable.
SmarterMail(tm) 17
MAPI over HTTP - Let's flesh it out with Exchange like features!
@Patrick Mattson That is the same problem we also have - we implemented a content filter that adds [EXTERNAL] to all mail subjects that originate from outside our domain and while it has been a very beneficial change (click rate on junk/spam has been reduced), it broke many content filters for our users (some work, some do not).
Ideally, SmarterMail should have a dedicated option for such a caution that can be enabled/disabled and configured separately, outside the Content Filtering system and which should not interfere with it.

Reply to Thread