AntiSpam strange behaviour

[koldun]

Hello everyone. 

Can someone please describe me why this example spam mail was delivered to user ? 

I attached a export from fortimail with an example, and it is looks like whitelisted value "notifications@monday.com" was marked as equivalent to  "bounces+6182960-837b-Name.Surname=My.Domain@emails.monday.com" that is present in From field. 

How is it possible ? 

Here is a detailed trace for a mail: 

[koldun]

Or at least if AS engine marks it as SPAM(and it is really do, good job), is there an option to modify subject, to prepend it with some [FortiMail=This Is Spam] part? 

[Bromont_FTNT]

I would start by asking why does notifications@monday.com need to be whitelisted? Why is the legitimate sender being quarantined if not whitelisted?

Also the Mail From: on the legitimate e-mail may not match notifications@monday.com either. Best to check the logs and make sure. 

[koldun]

this monday.com is just an example, there is many many different cases like this. 

So I would like to have some ways of improvement on FortiMail side, first. 

in other words, before starting to fight the windmils, I would like to be sure that my sword is sharp, and horse is strong. So I need to fix FortiMail settings first. And what I am see right now, is not looking good. 

[Bromont_FTNT]

I would suggest opening a support ticket to get this looked at. 

[koldun]

Bromont wrote:

I would suggest opening a support ticket to get this looked at. 

Good idea, but I think that this kind of discussion would be interested to many different fortimail users, and going support way is a hidden from public. Which does not mean that I didn't do that. I am going two ways at the same time :) 

[Joey]

koldun wrote:

Bromont wrote:

I would suggest opening a support ticket to get this looked at. 

Good idea, but I think that this kind of discussion would be interested to many different fortimail users, and going support way is a hidden from public. Which does not mean that I didn't do that. I am going two ways at the same time :) 

Just open a support case, your ideas are not helping anyone, and please RTFM.

[Carl_Windsor_FTNT]

>I hope that we both are agree that main here is a Mail From address,as it is represent a real

>sender address.  Header From is needed to change displayed address in outlook client.

Agreed that the Mail From address represents the originating sender of the email (assuming it is not forged) and is where any NDRs should be sent but the mail may be sent on behalf of another user e.g. in your case "notifications@monday.com" which is the address you wanted to safelist in the first place.  There is no point safelisting the FROM in this case as it changes "email=bounces+6182960-837b-Name.Surname=My.Domain@emails.monday.com" 

>How we need to modify that system to make it match whitelistings with Mail From addresses,

>and do not touch Header From?

If we did as suggested, you would not be able to create whitelist the example above I described.   Those user expecting to safe/blocklist emails based on the client Display Address (Mail From:) would be unsuccessful.  This is functioning as intended.

>Or maybe what else we can change, to prevent that kind of spam to be accepted ? 

Safelisting deliberately bypasses SPF as it is one of the biggest causes of non-delivery.  We could look at enforcing SPF whist bypassing other methods but it would have a major impact on those people using safelisting due to remediate bad SPF configs - there are a surprisingly large number in some pretty major organizations, including monday.com who have a PermError "too many lookups".

Ideally, to avoid misuse, you remove the safelist entry however, what has not been mentioned yet is why it was needed to safelist "notifications@monday.com" in the first place? 

[koldun]

It's a super feature, that maybe enabled by default, or was enabled by one of admins that was setting this up before me. 

This feature called "Outgoing Recipient Safelisting". 

Sometimes that caused a funny cases where user getting some spam, user have Out of office set, sending auto-reply, and that spam address automatically whitelisted for future spam mails. 

[Jeff_Roback]

I know this is an old thread, but it's still something we deal with every week.   I really agree that the current disabling of SPF checking for safelisted entries is very problematic.   See my thread about this here:   https://forum.fortinet.com/tm.aspx?m=161900

Carl, I disagree with your point here: 

Safelisting deliberately bypasses SPF as it is one of the biggest causes of non-delivery.  We could look at enforcing SPF whist bypassing other methods but it would have a major impact on those people using safelisting due to remediate bad SPF configs - there are a surprisingly large number in some pretty major organizations, including monday.com who have a PermError "too many lookups".

Bad SPF records are a problem, but spoofed from addresses are a MUCH bigger problem, in my opinion, as they're used as a method of attack and they come without warning.   Whereas a bad SPF can be configured to bounce to the sender, and that will get forwarded to an admin who can fix it with an exclusion.   Much easier to make an exclusion for the bad SPF's than to make an exclusion for every safe-listed item that still needs SPF.    Part of why this is so important is because end users have the ability to add things to their safelist, but I don't believe they should have the ability to add exclusions to SPF checking.

But more importantly I think the current design is a mixing of metaphors.... SafeLists should be for excluding spam checks, which are by their nature subjective.  But SPF should fall under the same category as av scans... they're a security measure with defined rules.  Otherwise we're letting someone skip the SPF check by letting them forge the very thing that SPF is intended to check for! 

However, I think with a couple additional options this could be made to work without a major change of processing: 

Here's what I suggest:

Add an option to enforce SPF even when sender is in safelist in an antispam profile like this:

and then add an option on the content profile like this

and then people can have it either way they want...  People can allow or disallow SPF during content or antispam checks as they wish.

Jeff

[Joey]

Jeff Roback wrote:

I know this is an old thread, but it's still something we deal with every week.   I really agree that the current disabling of SPF checking for safelisted entries is very problematic.   See my thread about this here:   https://forum.fortinet.com/tm.aspx?m=161900

Carl, I disagree with your point here: 

Safelisting deliberately bypasses SPF as it is one of the biggest causes of non-delivery.  We could look at enforcing SPF whist bypassing other methods but it would have a major impact on those people using safelisting due to remediate bad SPF configs - there are a surprisingly large number in some pretty major organizations, including monday.com who have a PermError "too many lookups".

Bad SPF records are a problem, but spoofed from addresses are a MUCH bigger problem, in my opinion, as they're used as a method of attack and they come without warning.   Whereas a bad SPF can be configured to bounce to the sender, and that will get forwarded to an admin who can fix it with an exclusion.   Much easier to make an exclusion for the bad SPF's than to make an exclusion for every safe-listed item that still needs SPF.    Part of why this is so important is because end users have the ability to add things to their safelist, but I don't believe they should have the ability to add exclusions to SPF checking.

But more importantly I think the current design is a mixing of metaphors.... SafeLists should be for excluding spam checks, which are by their nature subjective.  But SPF should fall under the same category as av scans... they're a security measure with defined rules.  Otherwise we're letting someone skip the SPF check by letting them forge the very thing that SPF is intended to check for! 

However, I think with a couple additional options this could be made to work without a major change of processing: 

Here's what I suggest:

Add an option to enforce SPF even when sender is in safelist in an antispam profile like this:

and then add an option on the content profile like this

and then people can have it either way they want...  People can allow or disallow SPF during content or antispam checks as they wish.

Jeff

Checking SPF is an AS feature, safelisting an email or the whole domain bypasses all AS, I saw your other thread but I don't believe the feature you requested is going to be implemented.

I've been running FML with 2x addresses in my safelist simply because I use safelist with caution.

I solve most of my issues by finetuning the config, safelisting is a last resort.