Fred,

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.

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.

 https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf

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.

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. 

Linking here another thread created 2 months ago on this subject: https://portal.smartertools.com/community/a93880/add-an-external-visual-warning-to-emails-coming-from-outside-our-domain.aspx

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.

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.

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.

Douglas:

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.

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.

@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.

Does anyone know how to get around the Base64 encoded issues with Declude? We add the banner with HTMLmarkup using Declude but it on Base64 encoded email it gets messed up and obviously plain text messages show the HTML markup.

Still wishing this would come to life with native support within smartermail. 

+1 

+1

Many questionnaires from cybersecurity insurance companies ask if this functionality is integrated into our messaging system. in 2022, it's a must.

I asked this in another thread and commented about how a couple of our O365 customers have been asked for this by their insurance company. 

+1

Agreed this seems to be an increasingly necessary feature. I would add it would be even more helpful to be able to turn it on/off on an individual user basis within a domain. I have a client whose main business does not require it, but employs attorneys who specifically need this functionality. So while some users would want it turned on, others may not.

Official reply from Smarter Tools would be appreciated.

This could be indeed a good addition if this would be configurable and switched on/off at domain level

We use the content filtering to verify if email is from within domain or external source, but the problem with this that it only check the email address field instead of check the email header, we noticed that spoofed emails always don't get marked as [external] emails and this cause the user to believe the email is coming from internal user which may lead to bigger security concern.

I think this approach have its own risks which needed to considered carefully before implemented.

I doubt smartertools will try to improve the solution by looking at the email header to see it match the email address before it tag the email but someone can only hope.

At some point this will be required for insurance.   +1 

Anyone from Smarter Mail want to chime in on this conversation.   It would be appreciated.

Wonder if this is on the Smarter Mail roadmap? I know a BETA is in the works. Maybe this is part of it?

Just wanted to give you a quick update on this one. We will be implementing an external sender warning system in the future, so I just wanted to let you all know it is coming!

Aaaaaamazing!

That is Excellent News!

This one hell of a good news for today!

Kyle Kerst: Can you please provide an expected date on this? 

Hi Jonathan. This functionality is currently available in the SmarterMail BETA. The new feature, named "External Senders", can be found in the General Domain Settings. 

Thanks, Andrea.

I think you will have a lot of downloads if the beta goes well.

That's the hope! Please send us any feedback you have so we can make this one of the best SmarterMail releases yet!

Has any progress been made on this? I see that the issue was/had been addressed in a beta version 3 months ago. Is there an expected date to roll it out in an actual release?

This is in the April 6, 2023 release. We're using it now. That build has many issues surrounding MAPI and some other kinks being worked on, but the external senders feature is great. 

Only discussions we've had internally are that we feel in some cases it's over notifying because it flags every message. 

We wish you could white-list some domains that are still part of the "organization" and trusted. Like special partners or subsideraries or mailing list mail servers etc. 

Thanks for the response. I just looked at the release notes for build 8495 and see it listed. Sounds like it's best to hold off until the kinks are addressed. We use MAPI and don't want to take a step forward and two back.

Wondering if anyone thinks that it would be useful to whitelist certain domains from NOT getting the body text. We have a couple official company tools/services that we consider internal that we'd like not to add the message to. It'd be nice to exclude certain domains from the warning. We've submitted an enhancement on the idea, but we're curious what the community thinks on it?

Yeah, a method to Whitelist some senders will be a good idea!

Wondering if this idea to whitelist certain domains is catching any ears?

+1 for the ability to whitelist domains from the external-mail disclaimer.  We manage IT for a large client using Exchange 365, and they have 2 external partners exempted from the warning banner based on domain and sending IP addresses.

Hoping we can get the "Completed" tag removed on this and/or Smarter Tools acknowledgement that the request from the community to have a tweak here is received.

Michael, start a new thread as a feature request?

Yea. Maybe you're right. I'll spin up a new thread with the feature request tag and will post back with link here after creating it. 

Feature added to the Community: https://portal.smartertools.com/community/a95437/exclude-whitelist-domains-from-being-treated-as-an-external-senders-getting-domains-caution-message.aspx

If you think this is a good idea, please add your voice and thoughts there. Maybe it will get some Smarter Tools eyeballs soon. Thanks, all!