SPF Validation is skipped for safelist members

[Jeff_Roback]

Not sure if others knew this, but it came as a big surprise to me.   When you add an address to the safe list, it's essentially telling the Fortimail to bypass SPF checking.  Yes,  in retrospect I should have realized this because SPF is one of the antispam checks which are ignored for safe lists. 

But this seems like a terrible idea to me because we're telling the system to skip over all antispam protection based upon the sender... and we're not checking to see if the person sending is who they say they are.   Essentially, we're doing Authorization without Authentication.  It seems like SPF checks should be MORE important for people in the safe list, not less.

This seems like a really big deal to me... because knowing that a company is going to mark it's most common business partners as trusted, you can then confidently spoof mail from that domain without having to worry about SPF checks.  I can see that we'd need a way to override the SPF check for certain business  partners that just can't get the SPF thing right, but these would be the exception.

I know that we can do a SPF check at the Session level, but when it fails there it only increases the reputation score, we don't have the option to set a specific action here, so we can't count on this being effective.

It really seems like there should be a setting for an action to apply under SPF in the session profile, or the SPF check should be moved (or added) to the content section so that having a domain on the safe list doesn't remove the ability to enforce an SPF check for that domain.

[emnoc]

You should review the  check seq for the FML to understand what is and not check

example

http://help.fortinet.com/fmail/5-3-6/admin/index.html#page/FortiMail_Online_Help/overview_01_24.html

[Jeff_Roback]

Yes I've read that in detail.  Also the 5.4 admin guide and the 5.4 command line guide.   I do understand what the device is doing... and that it's documented.  I'm just questioning the logic of it, it seems like an unintended design decision.

[emnoc]

Find the FML product manager he posts here a lot any bring it up, but SPF for a trusted domain  is probably not a requirement since the purpose of a trusted sender is "trust" and the SPF is a  mail-sender authentication process.

[HFalch]

No, it does not make sense that trusting an envelope sender would cause SPF checking to be skipped. I have to agree with Jeff that if anything it makes the SPF check even more important. Same with DMARC, which if that flow list is to be trusted is also skipped on safe list matching.

I've actually made a point of only adding domains to the system or domain safe lists after verifying that the domain has a valid DMARC policy.

If I add an IP address to the safe list it would more often than not make sense to skip SPF/DKIM/DMARC. But automatically trusting an e-mail address or domain, without verifying that the client sending on behalf of said address is authorised to do so, when there are validation mechanisms available... It seems daft, frankly. It undermines those mechanisms.

I'll be doing some testing of this, and I hope someone from Fortinet will chime in and clarify. If not, and my testing also indicates that safe listing breaks SPF/DKIM/DMARC checking, I'll raise a ticket.

[emnoc]

So in all of fml version "SAFE" means we disable any AS checks. That would be ALL AS checks, we can be selective here ;)

So unless the  revamp the FML or add  a feature to enable  SAFE but with  SPF checks , I don't know how we can enforce SPF checks or even DKIM, DMARC as far as that goes. Your right, any thing spoof  that's in the safe list could be allowed. is this  good ? Of course not.

Out of habit I always suggest don't rely on  solely on safe trusted senders and always deploys SPF  or DKIM on domain that you own and don't sendmail from. And ESA  that uses  either of the two, will drop spoof spam messages sent from these domains. So when you  set a "safe trusted sender" you actually are assuming they are safe ;) Both  of these AS filter aids are so easy to  deploy and should be mandatory imho.

[Dirty_Wizard_FTNT]

While I agree selective safe-listing would be nice in the future, the functionality you desire is already available with additional recipient policy and antispam profile. This lets you choose exactly what checks you want on or off for specific sender domains. Outright safelisting domains is generally ill-advised on FortiMail.

[HFalch]

Safe listing does not disable every check according to that list, content and antivirus checks are still run. Whether those are spam checks or not depends on how you define spam. I don't consider SPF and DMARC to be antispam techniques first and foremost either. They make it harder to spoof, phish and impersonate, rather than stop a significant percentage of incoming spam.

Appreciate the tip about using recipient policies with a custom profile. I'll probably do that for now, though it seems like a needlessly complicated solution. It also doesn't solve the problem of per user safe listing (short of disabling that), as that also bypasses all the same checks according to the specification.

I expect a security product to have sane defaults. Just like I expect a FortiMail to not be an open relay out of the box, I expect it to check SPF and DMARC when told to, and not skip it just because someone flagged an e-mail address (rather than an actual client IP) as safe. Like Jeff stated in his opening post, that is like doing authorization without authentication and makes no sense.

So yes, if they don't plan to change the defaults here, I'd say they do have to revamp the software to give us more granular control over what safe listing does.

I'm curious to see where the new impersonation analysis feature in 6.0 will fit into the workflow of the FortiMail engine. If that is disabled by safe listing as well, someone needs to rethink a few things.

[Jeff_Roback]

jwilkins wrote:

the functionality you desire is already available with additional recipient policy and antispam profile. This lets you choose exactly what checks you want on or off for specific sender domains. Outright safelisting domains is generally ill-advised on FortiMail.

I strongly disagree and I think you're missing the point.    We need to be able to have safelists that are controlled at the individual user level, and yet not have those safelists cause the system to skip SPF checks.  

Clearly the fortimail is designed with this in mind, or they wouldn't have user level safelists not to mention the "outgoing recipient safe listing" option to automatically safelist everyone they send to.   Safelisting shouldn't impact SPF checking  for the same reason it doesn't impact Antivirus scans.   

Safelisting should be used to skip subjective evaluations that are prone to false positives, not to skip objective checks like antivirus and SPF.    Further, Safelisting is a form of authorization, and it is intended to bypass antispam checks.    By definition it shouldn't have anything to do with the authentication provided by SPF.   The fact that they end up in the same area of the fortimail seems to be a design decision that is causing unintended consequences.   

Currently the system is like a bouncer at a nightclub who was told that they should ID (SPF) and frisk (Antispam check) everyone, except for people on the VIP list like the owner Bob, who should be allowed to skip the frisk (Antispam check).  But our thinks he shouldn't need to check ID's for people on the VIP list, he'll just ask everyone what their name is.  If they say Bob (or anyone else on the VIP list), they go right in, otherwise he'll check their ID and frisk them.  Kind of defeats the purpose, doesn't it?   Now EVERYONE who is impersonating a VIP gets to skip both the ID check and the frisk.

Frankly, the more I think about this the more terrified I get of the vulnerability this exposes.

[Jeff_Roback]

For what it's worth, I've raised this with the PSIRT team, and they've decided that changing this behavior would be a feature request, not a vulnerability, so I'm not sure it's going to change anytime soon.

To summarize... anytime you or your users add someone to a safe list, either manually via the Fortimail GUI, or by the automatic "Add outgoing email addresses to Safe list" function, or by releasing a message from quarantine, that sender will no longer have its SPF record checked for validity.   

So any address on a user or system safelist skips SPF validation.   This is by design, and the only way around it is to not use safe lists.

Jeff