Hi Scott,

Thanks for the great feature request! I'm going to get a ticket started so I can get your request over to our development team for consideration.

+1 Yes, this would be a really useful feature to help protect users from phishing messages that make it through the spam & virus filters.

Thanks, Emily!

You're very welcome, kevind!

+1

+1

+1

and add to that, possibly a way to delete every email from the same IP address too, across all mailboxes.

Under the Security page in Server Admin Settings/ SMTP Blocks. It would be great if when you add a domain or email address to block on this list, that the system would give an option to delete from domain inboxes or delete from all domains inboxes.

Would be great also if we could have Content Filtering at the server level, as opposed to just the user, so we could block all future phishing emails, such as the current "This account has been hacked! Change your password right now!" emails, too. Not sure how these are making it through all the anti-spam I have on my box.

Additionally, when a user is reviewing an email, allow them to report it to SM as spam, which would alert the system admin (me) to potentially add it to this server-level Content Filter.

Yes. I agree the "Mark As Spam" should be brought back. Please see and vote for this thread:

Could have really used this "find and delete" feature yesterday.  Had a phishing email sent to around 300 users with a link to login and upgrade their email.  Fortunately, most people are getting wise to this, but the support team took over 50 inquiries asking questions.  Not sure how many people actually clicked.

With 19 votes, it looks like everyone could use this feature. Please prioritize. Thank you.

I have two of those emails hitting pretty much every user on my box. Yes, search and destroy, but also review the IP numbers and if consistent, block them. If distributed, then just Content Filter. And allow for sharing rules with other SM servers, either through ST as a hub, or some sort of simple text-based definition packet that can be posted to a forum thread, copied, and imported by those who want to participate in that thread.

It's pretty embarrassing that we are unable to stop these from reaching our users.

+1 
Finding related (or same) message across multiple users and deleting them I could see being very powerful. We could use things like message-id, IP, sender, subject, etc paired with our index/searching to create a tool to remove "like" messages from all the users in a domain or server. 

Nice after the fact.

However, more powerful is before the fact.

"Mark as Spam" button can mitigate these big waves.

User feedback is important.

Ron

Here's a long-shot additional thought: Database the subject of all incoming emails. If a particular subject, ie; "This account has been hacked! Change your password right now!" reaches a threshold of, say, 25 in a day, flag it as spam. If they continue to come in, send them to trash.

Problem with matching just by Subject is it would catch items like newsletters, twitter, linkedin updates and banking announcements that have the same subject line and are legitimately sent to many of our users.

I think Matt Petty is definately on the right track. 

True. I have an event that emails me whenever an IDS rule is triggered, though. If this new feature were to work within that system, we could be alerted once an email with the same subject were to hit, say, 50 users on the box. Log in to the server, and if it's legitimate newsletter emails just leave it. If it's spam, block it.

+1

Bump. Hoping this enhancement request with 32 votes is on the short list for 2022!

Thanks!

You guys really have no idea what your asking for.  The risks associated with crawling a mail server and going into unrelated mailboxes and removing messages.  Have you thought about any of the compliance requirements or issues related to this?  Think about the risks you are adding onto yourself, your company and the risks associated with administrators making mistakes or poor decisions etc.  

How is this different from how current anti-spam, anti-virus apps work on mail servers? Don't they simply delete emails, too, server-wide, based on their own algorithms?

Thats spool not mailbox. Touching a users mail is BAD and in some cases illegal.  If you read our 2021 summary email, you see how we have customers all over the world and must follow compliance and legal requirements accordingly.

Touching a users mailbox = BAD.

Taking some of this into consideration in the spool = interesting but requires a lot more thought and possible complexity I think.

For example, if some of these high repetition emails used as examples here were detected on the local server I think we'd need to define "detected" and possibly include, or have the option to include, more than just the subject line.  Even then you may see the attack perpetrated simultaneously from a variety of IP addresses and EHLO's.

Assuming a GUI was developed to allow the admin to set some parameters for this, or perhaps for a number of different conditions, I'd want the option to let the domain and/or the user opt out of the default behavior following such a detection or perhaps chose one of several outcomes.

That get's us back into functionality, covered elsewhere here, as to whether the body of an email is actually altered with some sort of warning header or footer as M365 can do or there is a subject line tag or a deletion or a spam weighting that might trigger deleting or move to the Junk E-Mail folder.

To really be a solution, a selling point and to avoid becoming something that created a lot of support issues I think a lot of thought would need to go into it. and coming to a consensus would be difficult.

I am with Tim on this though.  Simply reaching into the inboxes would likely be perilous and be a great attack surface for a competitor trying to sell against ST by pointing out that it fundamentally violated a variety of requirements in a number of jurisdictions.

Tim, I understand the compliance issue. I know SmarterTools is a big company. I would say Microsoft is bigger.

Here is a page from their site that shows how to do it. I get the implications but if you have a known virus, malware, phishing that is in people's inboxes the only choices are (1) email the users and ask them to do that, (2) automation, or (3) hope the users don't fall for it and click. I'm sure there are but to me removing it is the only way that guarantees this. This would be up to each company to do and a policy should be in place to make certain that it is allowed. I know I have done this back in Exchange 2010 when a phishing attack hit a mail server.

And another document that shows how to do it under Exchange.

Totally agree that this is not an easy problem. I just saw it as an opportunity for improvement. Google was able to implement a mitigation feature with their premium edition: https://support.google.com/a/answer/7581662

Again, just thought it would be worth exploring some options. A targeted phishing attack on a domain with hundreds of users can turn into an all day project. 

This would be covered under the Spam Button concept, discussed elsewhere in the forums.

If there were a way to feed a server database of emails our users have marked as spam, and the server were to see many, many copies of the same email come in to other users, there would be some leverage to apply there, especially if that were to also feed into a ST centrally-located database, fed by SM admins who want to help feed the tool.

One email I'd love to stop in its tracks is the Domain Authority of America and all its variants. three of my customers have been fooled by the official-looking email and sent them money... never to be seen again.

Bump after 5.5 months as this request came up in another thread...

Bump for 2023. Just had a phishing attack to our domain that didn't get tagged as spam because it was from a legitimate mailbox. Unfortunately, people fall for the urgency and click the link which takes them to a fake login screen where they enter their password.

This feature would allow us to proactively remove the message. Or as a compromise, allow us to move it to the users' Junk Email folder.

what if you follow this concept but instead of deleting the mail or moving it to junk after manually tagging such a threatening mail, for example, you add a note at the top of the mail like:

The system administrators have classified this message as a threat with the intention of obtaining personal information from you for misuse purposes.

Would that at best solve the problem with compliance?

Maybe you could specify like different types of classification and then let the administrator select this via a dropdown list:

- SPAM

- Phishing

- malware

After that maybe select which measure is taken like:

- Include hint text to mail

- Include message text in mail and move it to junk mail

- Move to junk only

Thank you and greetings

Roger:

It is great that people are contributing here.  I definitely appreciate that.

I do still worry about changing anything in the body.

Assuming ST could recalculate and also hack the signature so that the integrity check passes on signed emails I think it opens up some potential problems legally.  It also has the potential to create a nightmare scenario during an SM update where all of the email in all of the domains fail to pass on a bug slipping through.

In general, if we were going to take these chances I think it should be something that can be enabled/disabled at the domain level if not even the user level.

I see value in them but I'm not sure the value outweighs the risk.

True, but something could be done. ST has a central server that is checked frequently for maintenance subscriptions, so a central source DB with these spam rules could be pushed out to our own SM installs. A private, home-rolled anti-spam network.

Leverage what you got.

@Montague WebWorks 

Yes, and we'd probably take a good look at something like that if ST head down that path and like the Leverage what you got comment although I think it would be a big load on something designed as a licensing server and also require a lot more code around it to deal with false positives or screening but if ST did take it on we'd certainly look at it, even as an add-on.

We have something similar now based upon an even larger base of user experience using Message Sniffer vectored using Declude.  

I have both those products. Are there settings or anything I should be looking for in terms of handling this issue?