We have realized a huge problem with our FortiMail 6.4.4 and FORGED Emails. They are getting detected as FORGED because of SPF record is not valid, but afterwards if a user has the forged sender Address in their Whitelist, the Email will get still delivered. This is totally useless because if anyone has for example firstname.lastname@example.org in their Whitelist and the Email is sent with Forged sender email@example.com, the Email gets first detected as SPAM, in the next step it recognizes the (real)sender is Whitelisted SYSTEM SAFE and then the Email is delivered anyway, even it was previously detected and categorized as Spam/Forged.
1) wetransfer.com publishes '-all' in its SPF record; so, if anyone sends an fake email address firstname.lastname@example.org AND you have correctly configured your fortimail (with an action != accept), that email will not pass to mailbox user
2) whitelisting is LAST resource method when you cannot solve a problem in another way
So it must be used carefully and monitored continously. It shouldn't be enable as a friendly feature for non- technical users.
I.e: i have seen a lot of cases when user whitelists its entire domain...
Fortimail has a strange behavior with SPF records that makes them quite vulnerable to sender spoofing. In short, if the user or the admin has added an address to a safelist, the SPF is never checked. I've raised this with support and PSIRT, but apparently it's by design and the answer was to tell people to not use safelists.
There's really no practical workaround - if you put someone on a safelist, then you have no ability to use SPF to check for spoofed addresses.
In FortiMail 7.0, there will be option to not bypass SPF/DMARC/DKIM for safelist
This is incredibly fantastic, so happy to hear this! This is really the only major problem we've had with FortiMail, but it's a big one, so having this taken care of will leave me feeling good again about recommending the platform to clients.