Fortinet FortiMail-100, Install Manual

Page: 130 / 174

Example 3: FortiMail unit for an ISP or carrier Transparent mode deployment
FortiMail™ Secure Messaging Platform Version 4.0 Patch 1 Install Guide
130 Revision 2
http://docs.fortinet.com/ • Feedback
Network address translation (NAT) must not occur on any device between the FortiMail
unit and SMTP clients, such as subscribers and external MTAs. Antispam scans involving
the SMTP client’s IP address, such as sender reputation, MSISDN reputation, session
rate limits, and mail rate limits, require the ability to correctly identify each source of email
by its unique IP address in order to operate correctly. NAT would interfere with this
requirement.
Full transparency is configured. Popular email services such as Microsoft Hotmail may
rate limit by an SMTP client’s IP address in order to reduce spam. If the FortiMail unit were
not transparent to those mail servers, all SMTP connections from your subscribers would
appear to come from the FortiMail unit. The result is that external mail servers could
throttle the connections of all subscribers behind the FortiMail unit. To prevent this, each
individual SMTP client’s IP address should be visible to external MTAs. NAT therefore
would also interfere with the requirement of transparency.
Protected domains and access control rules (sometimes called access control lists or
ACLs) are not configured. Instead, administrators will configure ACLs on their own internal
or external MTAs.
To prevent SMTP clients’ access to open relays, the outgoing proxy will require all
connections to be authenticated using the SMTP
AUTH
command, but will not apply
authentication profiles on behalf of the SMTP servers, as no protected domains are
configured. It will also not interfere with command pipelining. However, the outgoing proxy
will be configured to block TLS connections, whose encryption would prevent the FortiMail
unit from being able to scan the connection.
The outgoing proxy is enabled. Unlike other transparent mode deployments, because no
protected domains are defined,
all connections will be considered to be outgoing — that
is, destined for an SMTP server whose IP address is not configured in the SMTP Server
field in a protected domain. As a result, all connections will be handled by the outgoing
proxy. The built-in MTA will never be implicitly used, and the incoming proxy will never be
used. If a destination SMTP server is unavailable, the outgoing proxy will refuse the
connection. The FortiMail unit will not queue undeliverable mail. Instead, each SMTP
client will be responsible for retrying its own delivery attempts.
Unlike other FortiMail deployments, because the ISP or carrier uses a RADIUS server to
authenticate and/or track the currently assigned IP addresses of subscribers, the FortiMail
unit can combat spam using the MSISDN reputation feature.
The FortiMail unit scans SMTP connections originating from
both the internal and external
network.
• Scanning connections from the
external network protects subscribers from viruses
and spam.
• Scanning connections from the internal network protects subscribers’ service levels
and reduces cost of operation to the ISP or carrier by preventing its public IP
addresses from being added to DNS black list (DNSBL) servers.
Why should you scan email originating from the internal network?
Spammers often use a subscriber account to send spam, either by purchasing temporary
Internet access or, increasingly, by infecting subscriber’s computers or phones. Infected
devices become part of a botnet that can be used to infect more devices, and to send
spam.
Note: You could configure ACLs to reject SMTP connections from specific IP addresses if
required by your security policy.However, in this example, because no protected domains
are configured, ACLs are not required. For connections to unprotected SMTP servers, the
implicit ACL permits the connection if no other ACL is configured.