Deep Header Check and X-Originating-IP

[romanr]

Hi, does anyone got some details about the Black/White IP checking on the Fortimail? Esp on the use of the X-Originating-IP attribute? I always thought, that Blacklisted Sender IPs will not hit if the e-mail comes from a whatever not listed ip address unless " Deep Header Check" Option is used. Then the Fortimail will also look into the headers of the mail and apply antispam actions if it finds a listed IP in the header section of the mail. Exchange 2013 Frontent Proxy Service sets the X-Originating-IP Attribute in the mail header when transporting authenticated mail. Fine! When this outbound mail now gets routed to a Fortimail - The Fortimail will also check the X-Originating-IP attribute - even if Deep Header Scanning isn' t enabled... It also tells me, there is a SPF violation (even this is disabled on the session profile) somehow confusing.... Br, Roman

[romanr]

But in your outgoing AS profile you have " Treat SPF checking failed email as spam" enabled right?

No - And as I use a proper SPF record for this domain - Which does not include my private DMZ IP addresses, I would really already have recognized... I checked it a couple of times. On all policies that apply: from the log above: <snip> Direction out Policy IDs 1:3:1 </snip> None of those 3 applying policies had SPF checking or Deep Header enabled...

[Bromont_FTNT]

Ok, let us know what support says... I haven' t been able to block a blacklisted IP address based on X-Originating-IP even with deep header enabled.

[romanr]

Ok, let us know what support says... I haven' t been able to block a blacklisted IP address based on X-Originating-IP even with deep header enabled.

Yes sure - I update you here! I found that trouble with the totally opposite way - We got some users who are blacklisted on their internet access, but need to send via SMTPS over the Exchange. And those users where blocked due to normal Fortiguard Black IP scan on mails coming from Exchange - As Deep Scanning was disabled and the only thing new was the X-Originating-IP Attribute, which came with Exchange 2013 into this infrastructure - Postfix didn' t use it...

[Bromont_FTNT]

To be honest I' m surprised you don' t have SPF enabled in the AS or session profiles at all... typically the Fortimail would use the connecting IP for SPF check but if the connecting IP is in a private address range then it looks at the last Received header for SPF regardless of whether deep header is enabled.

[romanr]

SPF is enabled on all policies that would connect from the outer world - So only on incoming policies. Like Session policy which handles 0.0.0.0/0 and Access + Recipient policies that have outside sources. Especially in this situation - where the customer had to forward a lot of mail via his mail servers to the outside - we carefully watched not to check against SPF for mails from the DMZ based mail servers...

[Bromont_FTNT]

Any updates? Did you get the issue resolved?

[emnoc]

To be honest I' m surprised you don' t have SPF enabled in the AS or session profiles at all... typically the Fortimail would use the connecting IP for SPF check but if the connecting IP is in a private address range then it looks at the last Received header for SPF regardless of whether deep header is enabled.

I aggreed on this statement and is how I handle AS protection. I drop maybe 2-5% of email due to SPF checks thru-out the day. Not a lot but it helps. On the exchange-server, i would build a profile that does not use deep-header check nor SPF validation. This would prevent AS inspection dropping mail, that' s legit. You can always disable AS inspection for mail from trusted host but it' s adviseable to ensure proper mail from trusted inside relays. fwiw: Since " X-Originating-IP" covers the sender, you could build a ip based policy on this source/mask and allow this traffic.