Ken Felix Security Blog: Fortimail recipient verification using Jumpcloud LDAP

In this last series of working examples and by using the jumpCloud LDAP-aaS, I will demonstrate having a fortinet EmailSecurityAppliance & the concept of verifying recipient email-address.

A email has a RCPT TO: header which will be in the protected email-domain that we will verify.

This is common-practices with ESAs or email-gateways to verify & eliminate spam for an user that does not exist in the local email domain.com.

Just like in the my previous earlier blogs, " the JumpCloud LDAP-aaS can be use with these appliances to verify the recipient address " . The steps are out line here below and with diagram of possible deployments solutions.

1st create a LDAP profile as shown in one of my earlier blog postings.

http://socpuppet.blogspot.com/2017/03/jumpcloud-ldap-aas-with-fortimail.html

check here for an example of jump cloud bind and basedn

2nd apply the named LDAP profile for the email protect-domain

Mail Settings > Domains > LDAP User Profile

3rd VERY VERY IMPORTANT , apply a recipient policy and selected your LDAP profile under

Policy > Recipient

Keep in mind that recipient policies are very important in the FortiMail mail-processing , and please be cautious of the pecking order. Move and re-adjust the policies as required.

Send a test-email , in my case the email address ldap2@socpuppets.com is not a local mailbox on a fortimail acting as a mail-server so it was bounced

: LOGS:

1st match wins. So like in a firewall-policy specify the most specific 1st

e.g top-2-bottom ordering.

RCP-policy 111 info@socpuppets.com { no verification }
RCP-policy 12 *@socpuppets.com { verification via LDAP profile & w/jumpCloud }
RCP-policy 18 googleblogger@socpuppets.com { no verification }

The latter will never be match due to the "*" wildcard policy preceding it. So the ordering of the policy-id regardless of the assigned numbers are very very important !

And my final tip, always review the logs on the FortiMail ESA. If you have any matches, the event logs will reflect the policy # for that match and disposition.

A user that has not been verified will generate a bounce back and no delivery to any inside exchange servers .

By deploy a LDAP services and profile and using a LDAP-aaS provider like JumpCloud , will allow you to apply good anti-spam filtering and secure email delivery.

https://jumpcloud.com

Now here' some deployment diagrams. The 1st is supplement your local LDAP server with Jumpcloud as a fallback. Great for a enterprise.Org that's rebuilding or upgrading it local AD server but needs to have a active LDAP services available. Here we achieve this with SLB and priortizing ldap queries to the local LDAP server and fallback to JumpCloud when the local services are not functional , down or interrupted.

The next diagram shows a simple diagram that solely uses a single JumpCloud instance for recipient verifications purposes with multiple MUAs sending mail to valid and non-Valid Recipients.

And lastly, in a email-hosting provider arena & where you might have single or pair of ESA email-appliance that needs multiple hosted email protect-domains. Here you could craft multiple JumpCloud org-id and build multiple LDAP profile that's unique for each hosted email-domain.

A unique ldap-administrator could be assigned for each instance and controls his/her own scope and manage the ldap org tree and have a unique org-id and ldap-service account for that domain.

And for diagnostics ensure you test for ldap connectivity and the corrent syntax. Here we are using curl for testing LDAPS to jumpcloud