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
Always ensure the correct credentials and use the "-k" if your using cUrl and have not save the jump cloud public-cert.
Ken
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \