You have my word that I will share with the responsible team! As to the outcome, I cannot make promises, but I'll do my utmost!

I tried everything I could think of to get this issue resolved but was unsuccessful. I even opened a case...

While the referenced document is misleading, it can be corrected. There may already be a similar "TID" but they are difficult to locate with a dysfunctional search capability.

The only solution is to update the (already out-of-date) documentation. Perhaps you can make this point to those responsible?

I hope you will leave this "Tip" as is. It is just one more opportunity for customers to become aware of this Security Issue.

While this is a documentation issue, it is also definitely a security issue. I was under the impression that security issues were taken seriously and resolved expeditiously. Perhaps you have some internal contacts who are responsible for security issues? Something needs to be done and we all would appreciate any help you could provide.

Hello Kevin, appreciate your feedback! As you know, I am not the one writing up the knowledge documents. These are created and uploaded on the support portal by my colleagues in support. 

In this case, I'd like to remove the article completely as based on your feedback, it is completely misleading. Apologies for that. I leave it for another day, so that you'll have the chance to read my response. 

I'm really glad that you point out the issues with the article!

 Three years prior to your post I posted this.

Security Issue: What is SMG Internal mail? You THINK you may know...

When you say "Situation: There were issues with spoofed emails that were coming from the internal domain (internally).", that is misleading. The support article to which you refer clearly shows this email arrives on the SMTP interface.

Let me restate the situation.

SMG considers email arriving on the SMTP interface FROM an email address whose domain matches (one of) the internal domain(s) to be INTERNAL mail. This email will only be scanned by a scan policy that includes the "Handle internal mail" option.

Don't you think it is about time the documentation was corrected? Prevention is better than cure. The article to which you refer simply explains to customers how malware could have entered their system. Nobody configuring a new scan policy is going to see it nor take the necessary precautions!