Tuesday, March 28, 2017

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.


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


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.


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

Always ensure the correct credentials and use the "-k" if your using cUrl and have not save the  jump cloud public-cert.


Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
        /  \

1 comment: