Configuring endpoint reputation options
This procedure is part of the session profile configuration process. For general procedures about how to configure a session profile, see “Configuring session profiles” on page 482.
- Go to Profile > Session.
- Click New to create a new session profile or double click on an existing profile to edit it.
- Click the arrow to expand Endpoint Reputation.
The Endpoint Reputation settings let you restrict, based upon its endpoint reputation score, the ability of an MSISDN or subscriber ID to send email or MM3 multimedia messaging service (MMS) messages from a mobile device. The MSISDN reputation score is similar to a sender reputation score.
For more on endpoint reputation-based behavior, see “About endpoint reputation” on page 639.
- Configure the following:
| GUI item | Description |
| Enable Endpoint Reputation | Enable to accept, monitor, or reject email based upon endpoint reputation scores.
This option requires that your RADIUS server provide mappings between dynamic IP addresses and MSISDNs/subscriber IDs to the FortiMail unit. If this profile governs sessions of SMTP clients with static IP addresses, instead see “Configuring sender reputation options” on page 485. |
| Action | Select either:
• Reject: Reject email and MMS messages from MSISDNs/subscriber IDs whose MSISDN reputation scores exceed Auto blacklist score trigger value. • Monitor: Log, but do not reject, email and MMS messages from MSISDNs/subscriber IDs whose MSISDN reputation scores exceed Auto blacklist score trigger value. Entries appear in the history log. |
| GUI item | Description |
| Auto blacklist score trigger value | Enter the MSISDN reputation score over which the FortiMail unit will add the MSISDN/subscriber ID to the automatic blacklist.
The trigger score is relative to the period of time configured as the automatic blacklist window. For more information on the automatic blacklist window, see “Configuring the endpoint reputation score window” on page 643. |
| Auto blacklist duration | Enter the number of minutes that an MSISDN/subscriber ID will be prevented from sending email or MMS messages after they have been automatically blacklisted. |
Configuring sender validation options
This procedure is part of the session profile configuration process. For general procedures about how to configure a session profile, see “Configuring session profiles” on page 482.
- Go to Profile > Session.
- Click New to create a new session profile or double click on an existing profile to edit it.
- Click the arrow to expand Sender Validation. Configure the settings to confirm sender and message authenticity.
Failure to validate does not guarantee that an email is spam, just as successful validation does not guarantee that an email is not spam, but it may help to indicate spam. Validation results are used to adjust the sender reputation scores and deep header scans.
- Configure the following:
| GUI item | Description |
| Enable DKIM check | If a DKIM signature is present (RFC 4871), enable this to query the DNS server that hosts the DNS record for the sender’s domain name to retrieve its public key to decrypt and verify the DKIM signature.
An invalid signature increases the client sender reputation score and affects the deep header scan. A valid signature decreases the client sender reputation score. If the sender domain DNS record does not include DKIM information or the message is not signed, the FortiMail unit omits the DKIM signature validation. |
| Enable DKIM signing
for outgoing messages |
Enable to sign outgoing email with a DKIM signature.
This option requires that you first generate a domain key pair and publish the public key in the DNS record for the domain name of the protected domain. If you do not publish the public key, destination SMTP servers cannot validate your DKIM signature. For details on generating domain key pairs and publishing the public key, see “DKIM Setting” on page 397. |
| Enable DKIM signing for authenticated senders only | Enable to sign outgoing email with a DKIM signature only if the sender is authenticated.
This option is effective only if Enable DKIM signing for outgoing messages is enabled. |
| Enable domain key check | If a DomainKey signature is present, use this option to query the DNS server for the sender’s domain name to retrieve its public key to decrypt and verify the DomainKey signature.
An invalid signature increases the client sender reputation score and affects the deep header scan. A valid signature decreases the client sender reputation score. If the sender domain DNS record does not include DomainKey information or the message is not signed, the FortiMail unit omits the DomainKey signature validation. |
| GUI item | Description |
| Enable SPF check | If the sender domain DNS record lists SPF authorized IP addresses, use this option to compare the client IP address to the IP addresses of authorized senders in the DNS record (RFC 4408).
An unauthorized client IP address increases the client sender reputation score. An authorized client IP address decreases the client sender reputation score. If the DNS record for the domain name of the sender does not publish SPF information, the FortiMail unit omits the SPF client IP address validation. You can also enable the option to treat SPF checking failed email as spam. See “Treat SPF checking failed email as spam” on page 505. Note: Before FortiMail 4.0 MR3 Patch 1 release, you must enable SPF checking in the session profile before SPF checking in the antispam profile takes effect. Starting from 4.0 MR3 Patch 2 release, SPF checking can be enabled in either a session profile or an antispam profile, or both profiles. Note: Before FortiMail 4.0 MR3 Patch 1 release, only SPF hardfailed (-all) email is treated as spam. Starting from 4.0 MR3 Patch 2 release, you can use a CLI command (set spf-checking {strict | aggressive} under config antispam settings) to control if the SPF softfailed (~all) email should also be treated as spam. For details, see the FortiMail CLI Guide. |
| Bypass bounce verification check | If bounce verification is enabled, enable to omit verification of bounce address tags on incoming bounce messages.
This bypass does not omit bounce address tagging of outgoing messages. For more information, see “Configuring bounce verification and tagging” on page 634. |
| Sender address
verification with LDAP |
Enable to verify sender email addresses on an LDAP server. Also select an LDAP profile from the dropdown list. Or click New to create a new one. For details about LDAP profiles, see “Configuring LDAP profiles” on page 548.
|
Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!
Hi, on these instructions it states “personal black lists and white lists” on page 620.”
Where can i get the book to view page 620??
https://docs.fortinet.com/d/fortimail-5.4.0-administration-guide
That is a PDF version of the FortiMail documentation. 620 is referenced there.
Hello,
What about the confidence degree of Header Analysis (also called Deepheader Analysis)? The default value is 95.0, and statisticaly on dozen of emails, all the values are always within range 95,03- 95,09. What is really checked in headers ? In our organization (government – 5000 users) we have lots of SPAM catched but also lots of false positive catched by this feature…
Unfortunately the defaults are just “broad strokes”. A lot of tweaking is necessary to get things to where you are in your organization’s happy range of false positives vs missed spam.
Hello,
Do we have some addtional info regarding heuristic filter ? It is quite tricky to proceed with fine tuning with this light description. In my case, default settings just catch anything (around 10 emails out of 150’000… Now I have decreased threshold value to 3.0 and increased percentage of rules to 50% and now it catches around 200 emails out of 750’000 … still no false-positive.
Hello,
Is there a way to clear only one entry in the LDAP cache ? Since we have over 10’000 users and that there are multiple routers and FW between the SMTP Gateway and the LDAP servers we do not want to clear the whole cache.