Chapter 14. Recommended Configuration

In this chapter, you will learn the following:

• Ideal configurations for common and uncommon scenarios

• Recommendations on policy, filtering, and actions

• Architectures to suit a variety of different organizations

Best Practices

This single book cannot provide recommendations for all possible challenges sent down to the messaging team. I do hope to provide enough guidance to build a reliable and resilient gateway security architecture that requires low administration day-to-day, but is flexible enough to deal with the changes in tactics by the bad guys and the changes in business requirements that affect email.

Ultimately, the goal of your ESA environment should be to have 100% uptime for gateway email services. This is definitely achievable. Appropriate redundancy and disaster-recovery strategies are a critical component. The ESA is widely known for its resilience and reliability, with individual appliances experiencing zero unplanned downtime, but for email to be reliable end-to-end, other components also have to be in place.

Redundancy and Capacity

For a mission-critical application like email, redundancy is a chief requirement. I covered the topics of multi-ESA deployments in Chapter 13, “Multiple Device Deployments.” The generic architecture that I recommend includes multiple ESAs equally sharing the combined email traffic, either through equally weighted MX records or via external load balancing.

In addition to redundancy of the ESAs themselves, you must plan for redundancy in the services that the ESAs rely on.

Domain Name System (DNS) is the most important dependency of the ESA. In a typical configuration, the ESA makes 6–8 DNS queries for each incoming connection, and several more for delivery of every recipient. Certain features, like external DNSBLs, Envelope Sender Verification, and Sender Authentication with SPF and DKIM, can add even more queries. The total count of DNS queries from the ESAs can be 10–20 times the total SMTP connection count. Although most of these DNS-dependent features timeout quickly, without successful lookups their intended effect can be blunted.

There are three approaches to DNS reliability: Use the built-in caching DNS resolver on the ESAs, use multiple local DNS caching servers, or a mix of the two. By using the Internet Root Servers setting, the ESA’s own resolver can use the redundancy of the global DNS hierarchy. For local servers, you can specify a priority associated with each DNS server and so create a load balanced or failover relationship. You should always provide two or more local DNS caching servers. If you’re using the hybrid approach, it’s still a good idea to use multiple local caching servers even though the ESA will query most to its own resolver.

Once configured, any connectivity issues affecting DNS will result in email alerts, but you should also consider monitoring via other paths, like SNMP. The ESA exposes an outstandingDNSRequests object that will increase dramatically during an outage. DNS servers should also be independently monitored.

Lightweight Directory Access Protocol (LDAP) is another important dependency for ESAs when it’s being used. As with DNS, redundancy is critical for reliability: The only way to protect against failure of an individual LDAP server is to provide two or more. The ESA can load balance or fail over connections between LDAP servers.

The ESA does have resiliency in its LDAP-related features. LDAP Accept queries, because they operate at SMTP conversation, are more time critical, and you have two options when LDAP is unavailable: temporarily reject all messages or let the messages in without an LDAP check. Of the two, I recommend allowing messages in. Despite the additional volume of mail, it’s preferable to rejection, which effectively creates an email outage if LDAP is unavailable.

The other LDAP query types are performed after message acceptance, immediately before the work queue, and will be held there if queries fail. This will impact message delivery, but not acceptance. Like with DNS, LDAP connectivity failures will generate email alerts.

Securing the Appliance

Of course, reliability isn’t possible if the ESAs are compromised by an unauthorized entity, whether it’s a remote intruder or a local user poking around the network. It’s possible to make configuration changes on the ESA in a few seconds that would turn it into an open relay or disable security filtering. The ESA itself is designed to prevent unauthorized access, but it’s easy for an administrator to loosen restrictions and anyone with appropriate credentials and network access to an appliance can log in.

Standard security best-practices safeguards should be taken with the ESA:

• Limit access to the management interfaces using a network security device, like a firewall or with network ACLs: If the ESA has multiple IP interfaces, don’t enable the management protocols on outside interfaces at all.

• Establish a change control process for making configuration changes: At a minimum, this should include the file export process described in Chapter 10, “Configuration Files.”

• Use lowest privilege accounts: For day-to-day configuration, you only need Operator level privilege, not Administrator. Using a separate account with appropriate privileges for each authorized user not only helps prevent accidents but also assigns a name to every change, for auditing purposes.

• Don’t use insecure access methods: In the case of the ESA, this means don’t use Telnet, FTP, or HTTP. Use SSH for CLI and SCP for file transfer. Web-based access should use HTTPS only, with HTTP redirecting the connecting browser to HTTPS.

• Don’t use the default password: The ESA System Setup Wizard prompts you to change the admin password, but doesn’t prevent you from reusing the default—ironport.

• External logging: You should configure copies of important log subscriptions to be sent off-ESA via syslog or via FTP/SCP file transfer. The most important logs are the system logs, text mail logs, configuration history logs, and GUI/CLI access logs. You don’t have to stop logging locally, because you can just create an additional log subscription.

In addition to the standard safeguards, you should restrict access to the ESA by enabling these features:

• WUI inactivity timeout: The ESA defaults to 30 minute inactivity logout, which may seem inconvenient, but be wary of making this longer. Leaving yourself logged in to the WUI lowers the barrier to unauthorized access. This value is controlled in the Network Access page in the System Administration menu.

• Administrative access control lists: Limit the source IP ranges that are allowed to access the management interfaces through the adminaccessconfig command or the Network Access page in the System Administration menu.

• Strong password controls and login restrictions: If you’re using local administration accounts, limit the number of unsuccessful login attempts, and enforce some or all of the password complexity options. You can find these options under the Users page in the System Administration menu.

Security Filtering

The ESA’s default policies are designed to be effective right out of the box. If you set up your ESA using the System Setup Wizard, and the ESA can connect and download rule and engine updates, you will have an effective security policy immediately.

Of course, there may be room for improvement depending on your organization’s preferences. For one, you may prefer a more aggressive stance on spam than the default to catch more junk at the expense of a higher false positive rate, or conversely, a less aggressive stance to reduce false positives.

The settings for anti-spam, antivirus, and zero-hour outbreak filters are covered thoroughly in Chapter 8, “Security Filtering,” so I want to focus on connection and rate controls in this section, chiefly via the tools in the Host Access Table (HAT).

HAT Policy Settings

Earlier chapters covered the ESA pipeline and its security filtering. As stated, the ESA defaults are very good: They are restrictive enough to prevent overwhelming from external Internet senders and allow wide-open access to specified internal hosts.

If you want to move to more aggressive settings, my general guidelines on HAT policies are as follows:

• Rate limits should be as restrictive as possible for both internal and external senders. Very few legitimate senders will use more than a couple of simultaneous connections. If your clients connect directly to the ESA for delivery, and not through a groupware server, you can also limit total recipient counts to 100 recipients per hour or less.

• Internal hosts other than designated groupware and application servers should not be allowed to connect to the ESA to send email. Allowing SMTP relaying directly from internal user workstations will result in compromised hosts having a direct path to send spam and malware messages to Internet recipients.

• Set the listener global limits on connection timeouts. The ESA can disconnect senders that have been inactive for a while. There are two limits: a limit for unproductive connections that have resulted in no message data sent and a total connection timeout. Setting these to 1 and 5 minutes, respectively, prevents abusive or broken SMTP clients from monopolizing your bandwidth with idle connections.

• Set the listener global limits on connections. Each ESA model has its sweet spot for simultaneous SMTP connection handling, from around 100 on the 1U models up to 300–400 and 600–800 for the larger enterprise models. This will change with each hardware generation. It’s tempting to set this as high as possible, but handling large numbers of simultaneous connections, especially with TLS, can actually result in lower total throughput.

My recommended defaults for a restrictive ACCEPTED mail flow policy are detailed in Table 14-1. Defaults for other mail flow policies follow from this: THROTTLED should be more restrictive, and TRUSTED should be less so. The motivation here is not to completely stop messages by policy, but to make the sending of high-volume messages more time consuming. Legitimate senders, even large ones, do not consume massive resources in their attempts to deliver messages in bulk and will retry when you push back with restrictive HAT policies.

Table 14-1. Recommended HAT Settings

In some environments, you might find my recommendations too restrictive. Service providers, higher education, and retail environments may find that they need to support high volumes of mail from other similar organizations. It’s common to need to allow higher connection and message rates from the big four of webmail providers: Microsoft (Hotmail and MSN), AOL, Google (Gmail), and Yahoo!.

For those cases, I recommend a “pseudo-whitelist” HAT sendergroup and policy that allows more connections and higher recipient rates, but still applies security filtering. It’s not wise to disable anti-spam filtering from these senders, because compromised accounts in those environments are a big source of junk.

I don’t recommend these settings for cable, fiber, or wireless ISPs. Those types of service providers host residential and business customers with their own equipment. Because of the potential for spam-sending malware infections in those networks, even a pseudo-whitelist allows more spam in. I prefer to let the HAT defaults and SBRS sort these senders.

Table 14-2 describes the modified settings for such a HAT mail flow policy. Be certain to keep anti-spam and antivirus enabled on this policy.

Table 14-2. Sample HAT Mail Flow Policy for Large SPs

Once you have your pseudo-whitelist sender group, you need to add the senders to it, and the best way to do that is by domain names. Domain names in DNS are double verified by the ESA, meaning that each connecting IP is queried by PTR and the result A queried; to be considered part of a domain, the hostname returned by the PTR must have an A record that includes the same IP.

Table 14-3 gives some of the entry syntax for the major webmail service providers. Note that this information can change at any time.

Table 14-3. Webmail Service Provider Sender Group Entries

Whitelisting and Blacklisting

Security filtering, especially anti-spam filtering, is often subject to corporate policies or even personal whims. The common policy of manually whitelisting, or excluding some domains or senders from spam filtering, is one of these. Whitelisting is justified by the need to eliminate false positives in business critical communications, a laudable goal. There are several problems with the practice, however:

• The definition of sender varies. Users typically mean the visible From address, which, like all other SMTP data, can be forged. ESA normally uses the sending IP or its attributes, like SBRS and hostname, when referring to senders.

• Whitelists of senders are often imported from other solutions, where they’ve been added onto over many years. Any static list suffers from becoming outdated. Any two filtering solutions are unlikely to have the same false positive problem with the same senders, making imported whitelists fairly useless.

• Excluding some sources from filtering is a security risk. Even whitelisting based on source IP or verified hostname can result in threat messages being accepted and bypassing scanning. Even good senders can have their environments compromised and become a source of spam and viruses.

The last of these is especially important, because the landscape of threat messages has changed. It is no longer possible to simply describe spam as unwanted advertising. The anti-spam engine on the appliance defends against phishing, fraud, advertising, spyware, and malware spread through URLs in messages, and bypassing it lowers your security stance.

As a result, I take the position that whitelisting any incoming messages, by any criteria and for any reason, is a potential security risk. If you are requested to institute such a policy, you should be aware of the risk/reward that that policy entails.

Similarly, adding IP addresses or email addresses to a manual blacklist to reject or drop spam messages is counter-productive. It adds administrative and processing burden and is actually unlikely to make a dent in spam volumes because of the constantly shifting sources that spam senders use. However, there are some cases where it may make sense to manually block some senders:

• Senders that are harassing employees. HR may require that communication from some external email addresses must be stopped in order to maintain a harassment-free workplace.

• Senders involved in any kind of targeted security exploits or industrial espionage. Email is a popular means of contacting employees for soliciting insider information.

• Dedicated letter-writing campaigns. Organized senders of mass email, often through web-based forms. These campaigns are often political or policy focused, but if your organization decides it shouldn’t be allowed, you need to use policy tools to stop it.

• Policies that prohibit use or communication with major webmail or other service providers. If your organization has no need to communicate with senders on particular networks, or from other countries, you can use a HAT sender group to block these networks by IP range or domain name.

Of course, recommendations aside, you may find other reasons that you must have a policy to manually allow, or block, certain senders. The default ESA HAT includes a WHITELIST and BLACKLIST sender group that you can list IP addresses, CIDR ranges, domains, and network owners. The HAT is for invoking policy at connection time, although it does have the ability to block SMTP MAIL FROM addresses at connection time using the Exception Table. That HAT is not the place for blocking email addresses.

Once a message is accepted by the ESA, you can create policies for sender and recipient email addresses in Incoming Mail Policies. I find it convenient to pre-create a policy for blocked and allowed senders. Keep the Allow policy at the top so that it takes precedence over your other policies.

Figure 14-1 shows the incoming mail policies table with an allowed and blocked sender policy.

Figure 14-1. Incoming Mail Policies with Allowed and Blocked Sender Policies

Spam Quarantining

The anti-spam filtering features on the ESA have as an option to quarantine spam or suspected spam messages and store them for manual sorting later. You, as the administrator, can decide whether to quarantine or not. If you are quarantining, you can decide whether the stored messages are accessible to the end users or only to administrators.

Deciding to Quarantine or Not

The decision to quarantine messages is a business policy decision, not a technical decision. The primary reason for using quarantine is to protect against false positives—that is, messages marked as spam but that are legitimate. Because an anti-spam engine could potentially drop a legitimate business message, the choice is made to save the messages so that the recipient can sort it out for themselves. Many anti-spam products on the market focus on this capability, making up for inaccurate spam filters with generous end-user control.

Obviously, having an accurate anti-spam filter helps enormously to reduce the risk that false positives affect business, but there’s no such thing as absolutely and completely zero false positive rates. There are still several arguments against using a quarantine, and especially against end-user access to the quarantine:

• Overhead of storage and end-user access: Quarantines occupy disk space, either on the ESA or centralized on the SMA. End-user authentication can use standard enterprise credentials, but requires LDAP or POP/IMAP configuration.

• Judgment of end users: The ESA does not allow actual virus-positive messages to be easily sent to the quarantine, but it’s still possible for spam-positive messages to be dangerous. Phishing and other fraud, and malware distributed via URLs, come in email messages that are cleverly crafted and difficult to distinguish from legitimate sources. Giving users access to release these messages means the potential for those end users to gain access to fraudulent or malicious software that the ESA was designed to prevent them from reaching. Even with warnings, the additional step of using the quarantine UI won’t be enough to make all users sufficiently wary of releasing messages.

• Time and effort: Quarantining spam moves part of the work from the spam filter to the end users, requiring each user to dedicate time to sorting through messages. A major reason for implementing the ESA and its spam-filtering technology is to reduce the time and effort impact of spam on your environment.

End-User Quarantine Access

If you intend to allow end-users access to the spam quarantine web interface, you have a choice of access methods: via the URLs in the digest only, via the WUI directly with authentication, or both. Authentication of end users is via LDAP or via POP or IMAP login authentication against a mailbox server.

Digests are summary messages that display sender and subject of stored messages, along with Release and Delete links. There’s also a link to the WUI for that user’s spam folder. The user can always reach their quarantine space through the URLs in the digest, so as long as they have at least one digest message in their inbox, they can reach their messages. The administrator determines the frequency of digests from several times a day to once weekly or once monthly.

Because the digests provide all the information, control, and access that the spam quarantine offers, it’s not necessary to require direct authentication. A digest is generated for every email address recipient that has new spam in quarantine since the last digest. If users have more than one email address, use the alias consolidation feature so that the quarantine produces a single digest for all the messages for a given user, regardless of the address the messages were sent to.

Administrative-Only Quarantine Access

Another approach to the spam quarantine is just to use it as storage of last-resort before messages are deleted, restricting access to administrative users who can retrieve messages upon request. This increases the load on the helpdesk or messaging team, but eliminates the need for end users to be trained or to support their continued access to the quarantine. By eliminating that end-user exposure, you eliminate the risk that users will release messages that are cleverly crafted phishing messages. Assuming that administrative users are better trained, they can make a decision about a message’s threat potential before releasing.

Administrative access is the default for the spam quarantine unless you specifically enable end-user access.

Automated Notifications

In general, notification to end users, either senders or recipients, is counter-productive in security-filtering policies. Notifying users about viruses, spam, or dangerous attachments is likely to result in confusion and helpdesk calls.

You should take care that your policies never result in notifications to an outside organization. That is, you should never set a policy where notifications are sent to the sender of incoming messages or to the recipients of outgoing messages. This also includes bounces—you should never bounce incoming messages because of security filtering.

Ideally, your ESA configuration will never produce an automated reply, bounce, or notification to an Internet sender. In the case of spam, phishing, or other fraud, it’s likely that the sender address is forged, resulting in your environment being a source of junk bounces sent to other domains, sometimes called blowback or backscatter. A configuration that allows this will result in having your email servers blacklisted, a topic we discuss later in this chapter. The following recommendations for ESA configuration can prevent this from happening:

• Use LDAP or SMTP call-ahead recipient validation to reject non-existent recipients at SMTP conversation time. Do not use the options to bounce these messages in the work queue.

• Do not use the Bounce action in anti-spam verdict settings or content filters for incoming mail policies.

• Make sure that the destination hosts for the domains you accept mail for are reliably accepting that mail. The ESA can queue messages for hosts that are temporarily unavailable, but will eventually start bouncing undelivered messages depending on your settings. The default maximum queue life for a message is three days. This can be set higher, but three days is a long period of time for a destination system to be unavailable.

There are a number of cases where notifications or bounces make sense, of course:

• Notifying your internal senders about modifications or dropping of messages that violate policy: attachment rules, DLP, or other acceptable use. This can be useful if your policy expects that users will understand their mistake and correct it.

• Notifying your internal senders about undeliverable or delayed delivery of messages. ESA does not, by default, notify about delayed deliveries; you can enable this in Bounce Profiles.

• Alerts to administrators or security officers about spam, virus, or outbreak messages that trigger on outgoing messages. Alerting the sender rarely makes sense, because in most cases, they are unaware of the use of their credentials in these messages.

Being a Good Sender

The reception that your Internet email messages meet at a remote server has a lot to do with the battle being fought against junk senders. Recipient MTAs vary considerably in their policies and often don’t explain how or why messages are rejected or discarded. It’s easy to get caught in the net of some service-provider’s filtering rules. For most environments that send only user-to-user mail, sent by employees to other real people in modest volumes, you’ll rarely encounter these issues.

For larger environments with different kinds of email, both user- and machine-generated, trouble with delivery is an inevitable part of Internet email. Ultimately, the best thing that you can do is establish and enforce good sending policies. This ensured that your environment doesn’t get lumped into a “bad senders” group.

Being Rate Limited

Most organizations have MTA software or appliances in place that, like the ESA, can control SMTP connections and rate limit messages, and that can slow your deliveries to them. The ESA, as SMTP client, responds to this easily, using what is called the “good neighbor” algorithm. For every destination domain the ESA delivers to, it opens connections incrementally, one at a time, to deliver messages as quickly as the destination allows. If the volume of messages in the queue for that destination is small, it may use only a single connection. It attempts to reuse the connection to deliver multiple messages. If the remote side rejects or closes the connections, the ESA backs off and waits before opening any more.

You can override this behavior by setting maximum connection and rate limits in the Destination Controls Table, but there’s little you have to do to deal with being rate limited. The ESA delivers as much mail as possible without being too aggressive about it.

If you want to be preemptive about connection limiting to certain domains, or to all domains, change the Concurrent Connections setting in the Destination Controls table. The default on the ESA is 500 concurrent connections, which for all intents and purposes is unlimited. In SMTP terms, that connection volume is staggeringly high. Even a limit of just a few connections, 3–5 per destination, is enough to deliver thousands of messages per hour.

You can also put absolute limits on the rates of recipients being delivered to a given destination. For example, you might limit the ESA to delivering 1000 recipients per hour to an external domain. There’s not much call for this setting, however, unless you know specifically that a destination’s policies prohibit rates above a certain amount. This setting can be useful in controlling inbound delivery rates to servers within your network, like application or groupware servers, if you want to protect these systems from high fluctuating volumes. For example, most automated list servers handle bounces and unsubscribe requests, but may not be able to process more than a few per minute. Setting a rate limit using the destination controls table will allow the ESA to act as a shock absorber in the case of a high volume of bounces or replies. Messages will queue on ESA and trickle out as the rate limits allow.

Outbound Sending Practices

Most email administrators oversee environments that send many more kinds of messages than they realize. Email is treated by users as a sort of utility, always there, always reliable, and so they find ways to use it for many different purposes. Email is extremely popular for marketing, notifications, and customer communications. Application developers send alerts and updates. Ecommerce applications send statements, order receipts, and updates via email. Your IT organization may be expected to support this kind of traffic without question, but out-of-control applications and unsolicited messages can impact all email delivery in your organization, even messages unassociated with automated applications. For this reason, consider establishing policies for automated messages and ESA configurations to enforce them.

If your organization handles any kind of automated messages, special planning is warranted. Any message not specifically created and sent by a user (but by an application) creates additional risk because of the lack of human oversight. The ESA, as yet another application, can’t provide that oversight, but you can use the features to enforce policies.

In general, for any kind of bulk or automated email messages sent to external recipients:

• Prefer double or confirmed opt-in subscription services. For any kind of new subscription request, the new subscriber should be sent a message asking her to confirm her opt-in. Without confirmation, the address is not added to the subscription. Single opt-in, where the address is added to a subscription list once it is submitted, is subject to abuse.

• Prominently include an unsubscribe link or unsubscribe by reply—or both. In some jurisdictions, automated messages are required to have this by law.

• Use proper reply-able return addresses. In particular, the MAIL FROM sending domain must have an MX and be configured to receive replies or bounces.

• Manage your subscriber list and remove unsubscribed or unavailable mailboxes promptly. Keeping a clean mailing list is critical to being well received.

• Don’t use automatic reply software. Autoreply systems can be abused unless they have enough logic to prevent it. Out-of-office replies fall into this category, but are typically well tolerated.

• Rate limit your delivery of automated messages. In most cases, the ESA’s “good neighbor” delivery prevents overwhelming a destination host, but you can forcibly limit connection and deliver rates.

• Segment your traffic. Use the ESA VG feature, or separate appliances altogether, to deliver different types of mail from different source IPs. This shields you from a single blacklist stopping all of your outgoing traffic. If you segment your delivery using VGs, blacklisting of one IP because of a runaway application or mailing list won’t stop your user-to-user email while you work to fix the problem.

Traffic segmentation is somewhat arbitrary: You can divide your mail by source (application versus user mail) or by business division or sending domain. I like to roughly organize mail traffic into three categories with varying levels of confidence:

• High confidence: User-to-user mail or user-to-many mail, but generated and sent by a real person.

• Medium confidence: Automated, but high-quality messages, like order receipts, order status, paid subscription deliveries, and account statements. Generated by machine, but expected by the recipients and unlikely to be complained about. In general, these messages are individually composed to each recipient and sent in response to an action by the recipient.

• Low confidence: Other automated messages, from alerts and news articles to catalogs, coupons, and alerts. Almost anything generated by machine, and composed based on a schedule. Sent proactively, not in response to a particular action by the recipient.

Obviously, you should, at a minimum, consider a separate VG for each confidence category, but if you can spare the IP addresses, creating a separate outgoing VG for each application or source in your environment is ideal.

Handling Bounces

Maintaining a clean list of subscribers for automated mail means handling cases where recipient addresses being emailed by the application isn’t valid. There are a lot of reasons for invalid recipients: subscribers make typing mistakes, accounts get suspended, and sometimes messages get rejected for mysterious reasons. When the original sender is a user, he can read the text of the bounce message, correct his typo, and all is well. Application-generated messages are another matter—they have to interpret bounces and decide what to do with them.

I described DSNs in detail earlier in this book, but in summary, there are two kinds of bounces: conversational and nonconversational. By default, the ESA generates a DSN for the message that was rejected at SMTP conversation time during its delivery attempt. Nonconversational are the ones that are generated by the remote side, sometime after the original SMTP connection. To the ESA, the original message is recorded as successfully delivered; the bounces come later.

The DSNs generated by the ESA are predictable in format, while the nonconversational are not. The software that manages the mailing list must be able to accept and parse these bounce messages and take the appropriate action. If the software in your environment requires a specific format, you can use the ESA’s bounce templates, available in the Text Resources page of the Mail Policies menu, to compose custom bounce messages.

In most cases, a bounce means an unreachable recipient who should be removed from the address list. What that entails depends on the software.

If your application or mailing list software can’t or won’t remove a particular subscriber, you can use the ESA’s policy and filters, or the dedicated Global Unsubscribe table, as a last resort. Global Unsubscribe is available only in the CLI unsubscribe command. I describe it as a last resort because applications really do need to manage their subscribers properly, but in some cases, it’s not possible to act quickly on that. In some environments, it’s not even clear who owns or administers a particular offending application. ESA is another tool in your pocket for those cases.

Variable Envelope Return Path

If any part of your business sends bulk, automated email, handling bounces can be the single most challenging part of your email infrastructure. When a bounce is generated on a remote site, you have no control over the contents and format and, in fact, it doesn’t even need to be in the same language as the original. These bounces can be hours or days after the fact. The bounce your application receives may have no reference whatsoever to the original message, leaving a mystery as to which recipient you need to act on.

Variable Envelope Return Path (VERP) is an approach to message addressing that can eliminate this mystery. VERP is not a feature of the ESA itself, but an approach that many mailing list software packages support, and a technique you can use with in-house applications.

The approach is simple: The only attribute of a bounce that can be relied on is the recipient address. That recipient address is, in turn, created from the envelope sender address that you used in the original message. The VERP approach is to modify that sender address so that it contains information about the original message.

For example, if I’m accustomed to sending out order receipts with a return address of

[email protected]

When one of these receipts is undeliverable, the bounce ends up going back to that mailbox. The remote site composes a bounce that looks like this:

From: MAILER-DAEMON <mailer-daemon@isp>
To: [email protected]
Subject: Undeliverable
I'm sorry, I couldn't deliver your message. Remote server said:
550 – No such user

Well, that’s not helpful, is it? There’s no reference whatsoever to the earlier message—none of the original headers or body, or even a record of the original recipient. You can tell that this had something to do with the “orders” mailing list because of the To: address. That’s a fact that we can exploit. Instead of a static sending address, a VERP scheme might use a return address of

[email protected]

For a message whose recipient address is [email protected]. The original recipient is encoded into the sender address, with the delimiter + separating the list from the subscriber and = replacing the @ sign. Now if this message bounces, that encoded address is the recipient, and you can easily see the list member in question. You can go further with VERP, encoding other information, such as the list name or a subscriber ID. Because VERP is created and consumed only by your organization, you can use it as you see fit, subject to the limits of email address lengths.

VERP has its limitations. Because you’re encoding a single recipient in the envelope sender address, and there’s only one per message, your messages must be single recipient or be split into single recipients. Some security filters that act on sender addresses, like graylisting or challenge-response schemes, don’t deal well with variable email addresses, although those two particular anti-spam techniques have mostly disappeared.

DNS and Sender Authentication

Any host sending mail on the Internet should have forward-and-reverse DNS matching. Before you deploy a new ESA host, make sure that all the routable IPs it uses, or the outside NATted IPs it uses, have PTR records in DNS that provide a proper hostname, and that hostname’s A record matches the IP. You should also go one step further to match the hostname in the ESA IP interface so that the banner hostname in SMTP matches again.

Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM) are recently introduced protocols that attempt to add a layer of authentication to email messages for the purposes of reducing fraud. I discuss these thoroughly in Chapter 15, “Advanced Topics.” You should strongly consider using these authentication methods in your environment.

Dealing with Blacklisting

If your organization has never found one of its email-sending IPs on a public DNS blacklist (DNSBL), or been on a list of banned IPs by a major ISP, you’ve been extremely lucky.

How do you know if you’ve had an IP added to a blacklist? Typically, you receive no notification or alert about blacklisting as the only indication is in the SMTP 5yz response code to connections or commands, which is recorded in the bounce message that the ESA generates back to the sender. On the ESA, a backup of messages in the delivery queue or a high number of attempted messages for a particular host can indicate a blacklisting. If you suspect a blacklisting, there are a few places you can look for confirmation:

• hoststatus command or the delivery status page for a given domain. The “Last 5XX error” displays the most recent rejection and the human-language reason.

• Text mail logs, SMTP conversation logs, or domain debug logs. These log types record the SMTP response code and text verbatim.

• Telnet to one of the hosts for the destination domain in question. Most hosts reject the connection with a 552 or other 5yz SMTP response code at the banner level and immediately close the connection.

Here are a couple of examples of the messages you might see that indicate a blacklisting. The first is specific to the ISP recipient domain:

550 mx1.isp.example.com
ERROR: Mail Refused - <1.2.3.4> - See http://security.isp.example.com/cgi-bin/
   block-lookup?1.2.3.4

The second example is one where the recipient domain is using a third-party DNSBL that has your IP listed:

554 Service unavailable; Client host [1.2.3.4] blocked using SpamCop; see http://
   www.spamcop.net/

Blacklisting of your IPs happens for one or more reasons:

• Complaints from end users. Any service provider that allows end users to report spam or fraud messages will block IPs that are a consistent source of complaints.

• Sending from IPs in ranges considered part of residential broadband networks. Most cable, wireless, and fiber-optic broadband providers maintain separate networks for business versus home use. Many of the residential networks aren’t authorized to send email or host websites, and other ISPs will often reject connections from residential IP ranges.

• Incorrect or missing DNS information. Sending IPs with no PTR are almost certain to be rejected. Hosts that have DNS mismatches may be heavily rate limited or rejected.

• Too many delivery attempts to nonexistent accounts. These attempts look like “dictionary attacks” that attempt to find valid accounts.

• Activity on other ports and protocols. IPs being used as the source of malware, worms, DoS attacks, or even network probes are often blacklisted. In short, SMTP blacklisting might be rooted in a cause other than SMTP behavior.

Each blacklisting service or ISP offers its own methods of investigation and remediation. Most use a web-based form, where you can query the database and request an immediate removal or reevaluation. Your process for resolving a blacklisting should be

1. Examine the report from the blacklist or ISP and understand the source of the issue. If it’s the IP address of one of your external gateways, look at the message data to determine the original sender. Use the ESA logs to find the original injection source.

2. Resolve the root cause. Was the message injected by an infected system? Clear the infection, but also revise your relaying policies to prevent infected systems using corporate mail services. Was it due to a runaway application? Make sure the owner is aware, and revoke the application’s privileges until the issue is corrected.

3. Request the delisting. Most of the blacklist services and ISPs have a simple form for requesting a delisting. What happens next depends on the service: Some are automated systems that will remove the IP immediately, but reserve the right to re-list if the issue occurs again. Some have a provisional removal process, which lasts for 24–48 hours, where the IP will not be relisted, even if new reports are provided.

If you request a delisting without investigating or resolving the root cause, you’ll likely be relisted in short order. If the root cause appears to have simply disappeared, by clearing an infected workstation, it’s likely that at some point another infection will cause you to be relisted. It’s worthwhile to investigate the source and put an obstacle in the path.

Compromised Internal Sources

In many email environments, the challenges presented by user behavior are as acute as those presented by public Internet senders. Two chief user behaviors can result in trouble for your entire email environment: infection of workstation operating systems with spam-sending malware, and user account credentials being compromised. Either one of these can result in an insider becoming a spam or virus source that uses SMTP to further the spam cause.

I’d love to have a silver bull for client desktop infections, but that’s certainly out of the scope of this book. Instead, we must deal with the possibility of infections using SMTP.

To prevent infected machines that have their own SMTP client from delivering junk mail directly to the Internet using your environment, you have to take two steps: denying ordinary desktops from making direct port 25 connections to Internet destinations, and denying them from using your ESAs as a relay host. The first must be done with a network security device like a firewall. It may be possible to do this on the desktop operating system with a “personal firewall,” but many malware systems are capable of disabling such protections.

Denying relay access to local hosts on the ESA is fairly straightforward with HAT policies. To allow relaying in the first place, the HAT must have a mail flow policy with a relay behavior. A default ESA configuration has a sender group called RELAYLIST and a policy called RELAY specifically for this purpose. This sender group is empty by default, and you should limit your entries to the short list of authorized sending hosts: specific groupware and application servers that you know are a source of mail. Add senders by individual IPs or hostnames, provide a good description in the comments field, and remove old entries as they become dated. Adding large network blocks for internal hosts to RELAYLIST is a recipe for disaster.

If you’re using a single listener for incoming and outgoing mail, your default HAT will have the RELAYLIST at the top and the WHITELIST, BLACKLIST, and other groups afterwards. At the bottom is ALL, where unclassified senders end up. The ALL group has an ACCEPTED policy by default. Figure 14-2 shows this default configuration.

Figure 14-2. Default Public Listener HAT Policy

Let’s suppose an internal client machine, infected with spam-sending malware, connects to this listener. It won’t fall into the RELAYLIST, because you’ve smartly limited that group to a small set of hosts. It’s unlikely they’ll fall into the other groups, especially if you’re using RFC 1918 private address space, because those IPs won’t have SBRS scores. They’ll fall into the ALL/ACCEPTED bucket. This infected machine will be able to connect, but because of the RAT, will only be able to send to local domains. That’s pretty good, because it prevents the infected machine from turning your environment into a spam source for the entire Internet, but it does let an internal machine send to other local users. We can do better by manually classifying your internal networks and creating a sender group and policy. This is easy to do if your internal network space can be easily summarized, as with RFC 1918 networks.

Figure 14-3 shows such a HAT configuration.

Figure 14-3. HAT with Specific Handling of Internal Address Space

If you have two or more listeners, with a private listener for outgoing mail, your task is simpler. You still have a RELAYLIST, which should still be kept to a bare minimum of entries. The only other group is ALL, and in this case, the policy should be BLOCKED. In other words, any client that connects either has specific relay privileges or is not allowed to send mail at all. That HAT configuration, which is the default for new private listeners, is shown in Figure 14-4.

Figure 14-4. HAT Exclusively for Outgoing Mail

When you have an “outgoing only” listener like this, you’re not limited to relay-or-nothing policy. You can provide multiple relay behavior policies, each with its own appropriate connection controls and rate limits. This approach is ideal for controlling runaway applications before it happens; just because a server needs to send Internet email doesn’t mean it needs massive concurrency to do so.

Figure 14-5 shows an example. There are policies for application mail and a generic throttled relay policy for other uses.

Figure 14-5. HAT for Multiple Relay Privilege Levels

Bounce Verification

Earlier, I described problems with sending bounce messages, notifications, or any kind of automated reply message. So many sender addresses are forged that automatic replies go to unassociated third parties, making legitimate organizations become a nuisance. This can go on in your environment without being obvious. One of the most important things you can do, for your own environment, and for others, is not to be a source of this “backscatter.”

Figure 14-6 shows in concept how this works. In most cases, the backscatter is unintentional, the result of automated messaging and bad policy, but the bad guys have figured out that they can also use it deliberately. Either way, it’s not their problem, as the messages get bounced to someone else.

Figure 14-6. Email Backscatter Problem

What if you’re the victim of this sort of attack? Consider a situation where the perpetrators of a fraudulent email message send millions of copies of that message to as many recipients as possible. They use an email address at your domain as the sender address. Most of the messages will be filtered and dropped by the various recipient hosts across the Internet. Some of the messages will be rejected. But, some sites have the problem described earlier: They will accept the message at first and bounce or reply to it later. If the volume is low, the resulting automated messages can be just an aggravation, but in higher volumes, the message traffic can become a DoS attack.

HAT policies that rate limit or reject based on SBRS can mitigate the issue. Legitimate senders that are routinely used for backscatter attacks will find their reputation scores dropping or have their IPs listed on DNSBLs, allowing your ESA to automatically move them into an appropriate policy. This will not necessarily stop all these messages, and your own local policy may override the SBRS settings for some senders.

Another option is to simply drop DSN messages, as indicated by a blank envelope from address, with a message filter like this:

drop_dsn:
if (mail-from == "^$") {
   drop();
}

Using a simple filter like this is a pretty blunt instrument, dropping any bounce regardless of source. The ESA has a feature specifically designed to prevent backscatter from becoming a denial of service (DoS) attack, without dropping legitimate bounce messages: bounce verification.

The concept behind bounce verification is simple: First, mark up messages leaving your environment through the ESAs. Look for that markup on any bounce messages, where a bounce is indicated by an email with a null return address. If the original markup is present, it means that this is a bounce of a message that originated in your environment. If the markup is missing, the bounce is fraudulent and can be rejected or dropped.

The markup that the ESA uses is in the envelope sender address. It actually modifies the address stated in the SMTP MAIL FROM command with a hash of a secret key and some timestamp information. For example:

[email protected]

This is altered to

[email protected]

prvs stands for private signature. This method, and the acronym PRVS, come from the Bounce Address Tag Validation (BATV) Internet draft specification. The visible From: header and other SMTP headers are not modified.

Because the envelope sender address is intended for MTA-to-MTA use when sending status messages, normal mail traffic will not be affected. When a recipient receives the marked-up message in his inbox, the envelope information is discarded, and the user sees only the normal From: header. Replies and forwards work as normal. It’s only when a message bounces, and a DSN is created, that the difference emerges. In that case, the remote MTA composes the bounce with a blank sender address (<>) and the tagged recipient address. The ESA receives the bounce, verifies the tag, and removes it before delivering it as normal. Features that act on recipients, like LDAP accept and RAT, are checked after the tag has been removed.

Before you deploy bounce verification, there are a couple of architectural recommendations:

• You should tag all outgoing mail. This is easy to do if you adopt the “last hop out” architecture with ESAs. Share the tagging key across all of your ESAs. Untagged bounces look fraudulent and will be rejected.

• ESA should be the “first hop in.” The prvs tags are specific to the ESA and only an ESA with the same tagging key will be able to verify and strip it. Centralized management (CM) ensures that bounce verification settings are identical on all ESAs. Tagged recipients will likely be rejected or bounced if they get delivered through another MTA or directly to your mail store servers.

Enabling it on the ESA is simple. First, create a tagging key on the Bounce Verification page in the Mail Policies menu. Decide on the action to take with invalid bounces: Either reject them outright or accept them and add a custom header. Rejection is higher performance, but adding a header allows you to act on them in content filters with nondestructive actions.

Once enabled, you must invoke the tagging and the verification in the Destination Controls and HAT mail flow policies, respectively. These are simple Yes/No settings.

I hesitate to recommend bounce verification unilaterally for all environments, because of a few problems with the way some recipients handle addresses and bounces. Once the message is delivered, the envelope sender address really shouldn’t be visible to the end user, but some systems insist on using it in place of From, making it visible to the recipient. That can lead to confusion, and replies to that address end up going to the wrong place.

Any scheme that modifies sender addresses, like bounce verification or VERP, runs the risk of interfering with systems that key on the envelope address.

Bounce verification may be overkill for everyday preventative use, but during a DoS attack that brings email to a halt, it easily and quickly remedies the issue and restores service.

Recommendations for Specific Environments

Throughout this book, I used the term architecture to refer to the complete email environment for an organization. In some cases, I use the term to refer to just the ESA (and any SMAs) and, in other cases, to all the servers in the path of email flow or that depend on email.

Chapter 13 described the planning, deployment, and administration of environments with multiple ESAs, which as it turns out, is nearly all of them. I made recommendations for load balancing and centralized management. In this section, I give specific examples of the challenges faced by different organizations and some possible architectures to meet those challenges.

Obviously, email environments have been around longer than the ESA, longer even than the World Wide Web, and it’s unlikely that you’ll find yourself building a completely new environment from scratch. But, if you’re planning an ESA deployment, or just contemplating some changes with an existing one, these templates will hopefully provide a good starting point. Of course, the recommendations on security settings, policies, administration, and multidevice deployments from other chapters apply here, too.

I break down the recommendations first by size of organization, because email volume tends to follow user count: more users, more email, both legitimate and otherwise. Larger organizations tend to have more network egress points, more email groupware, and client locations, and more servers for supporting protocols, like DNS and LDAP. Complexity often follows from size.

It also makes sense to break down the recommendations by type of end user. Higher education, which typically favors less centralized control and strong aversion to policy, presents some challenges that no other organization will see. Service providers and higher education often have one major handicap: little or no direct control over the sending client.

Small and Medium Organizations

Small and medium-sized organizations, with up to about 5000 users, tend to have their email gateway environment hosted in one physical location, with all users in a few locations. These environments aren’t without their challenges, but because volumes are typically modest, the count of ESAs is lower. It’s not always true but small organizations tend to have more uniform policies and fewer sources of email to start with.

Throughout this book, my recommendations have already been mostly focused on this type of environment, with special exemptions for special cases like automated messages. The ESA’s default settings are an ideal place to start for deployment:

• Multiple ESAs should all be configured identically for handling both inbound and outbound. ESAs that are handling all traffic are better utilized, sharing load evenly rather than overwhelming one or two while others are idle. It’s also easy to remove an ESA for maintenance, administration, or replacement.

• Load balance using equal-weighted MX records for all ESAs. Hardware load balancing is overkill for four or fewer ESAs, but certainly useful if you have them.

• Take care with public webmail interfaces to groupware servers. Webmail is convenient for employee use outside of the office without requiring a VPN, but the single-factor authentication of corporate webmail interfaces make it a prime target for attackers. Phishing users for their account credentials is widespread and, once compromised, provides an open avenue for sending. Webmail servers rarely provide rate limits or other outbound controls.

Large or Complex Organizations

The criteria for being a large organization isn’t just numbers of users, but complexity and higher message volumes that tend to follow high user counts. If you have multiple physical email egress points, with users and groupware servers in many different locations, your environment falls into this category regardless of user count.

Automated messaging from databases, web servers, and in-house applications are also a common feature of larger organizations. Throughout this book, I stressed the importance of controlling and segmenting this traffic to maintain the reliability of email as a whole. In large organizations, email administrators are less likely to know about or be informed of automated applications, and there’s a tendency to treat email as a general always-on utility.

In addition to those recommendations, I can add the following:

• I prefer identical configurations across all ESAs, even if they will be deployed in separate roles, such as primary/DR or inbound/outbound. Identical configurations are easier on administrators and makes replacements easier when necessary.

• Load balance via equal-weighted MX records or using external load balancing. Load balancers with client stickiness have some advantages in larger email deployments, by sending the same client IP to the same ESA, making rate limiting and DHAP more effective.

• Segmenting of traffic is a must. At a minimum, separate email delivery over different outbound VGs based on confidence categories.

• Consider a multitier architecture if you have significant internal-to-internal traffic or routing between divisions.

• Consider a “large message” architecture if your policy allows for large attachment sizes. This approach can improve average throughput and reduces worst-case performance, making performance more predictable.

Service Providers

Service providers (SP) that handle email for clients tend to handle lots of it, and that distinction—volume—is what separates service providers from other kinds of email environments. These environments are challenging to design reliably because of high and often wildly fluctuating email volume, and the possibility of abuse resulting from client activity itself or responses or retaliation against clients.

Certainly, SP environments based on ESA have a large number of appliances, often in multiple locations. The recommendations for other large environments hold true here, too:

• External load balancing via hardware or DNS, or multiple IPs per A record, is almost always a requirement. Publishing dozens of hosts in MX records can result in very large DNS query results that exceed UDP payload limits. This forces the connecting client to shift to TCP, something a lot of environments can’t handle. In short, very large MX records can cause SMTP clients to break.

• For multiple physical locations, combine ESAs with centralized management, reporting, and tracking on a per-location basis. Each location pod requires separate configuration and reporting, but you avoid sending high volumes of data and configuration information over WAN links.

• Make use of LDAP or SMTP call-ahead for as many features as possible. Many SP environments have domain lists and aliases that exceed the ESA’s static table capacities.

• Aggressive connection rejection and rate limiting helps to keep message volumes down. If you plan to reject senders based on their DNS lookups or blacklist membership, it’s helpful to senders if you explain the rejection reason in the SMTP banner that you can customize in each HAT policy. That way, if aggressive controls affect a legitimate sender they can correct their mistake.

Higher Education

Higher-education organizations encounter the same planning and policy challenges in email security that other environments do, plus an ever-present battle between privacy and academic freedom on one hand and security on the other. Filtering email messages for text content, attachments, and other policy reasons may seem intrusive, but administrators are responsible for keeping an environment running properly and in compliance with regulation and organizational policies.

Often, the opposition to any kind of filtering even extends to spam and virus filtering. Some departments may prefer to manage and maintain their own email infrastructure for this purpose. If that’s the case, it’s a good idea to treat those mail environments as separate organizations altogether.

In addition to the usual email architecture recommendations, I can add the following:

• Use LDAP group policies to allow departments and offices to define their own restrictions and filters. Predefine policies for aggressive, conservative, or moderate spam filters and allow users a means of setting their preferences in the LDAP directory.

• Segment delivery traffic. The usual recommendations on user-to-user versus automated mail apply, but also consider separate delivery of student, faculty, and staff-originated messages.

• Provide SMTP AUTH services for clients directly on the ESA, preferably on a separate submission host and port.

This last item warrants more thorough treatment. The most unique aspect of higher-ed environments is the common need to support many roaming user mail clients without requiring VPN or other network connections. For inbound mail, POP or IMAP services are provided to clients, and these protocols don’t directly impact the ESA. For sending mail, however, SMTP AUTH is used to authenticate connections over the public Internet, and messages that are submitted are granted relay behavior when authentication is verified. ESA can provide this capability and offer some policy control.

It seems simple to allow for SMTP AUTH directly on your MX hosts on port 25, as all other messages are. However, there are distinct advantages to separating this submission traffic from your regular messages, and in fact, TCP port 587 is reserved specifically for this purpose. You can provide this submission port on the same IPs as your port 25 MX hosts or on separate VGs. The advantages of keeping submission separate are as follows:

• You can allow any source IP to connect. Students and faculty are fond of delivering mail from broadband, DHCP, and wireless IP source ranges, all of which may score very low in SBRS. A default ESA configuration will reject these senders at connection time.

• You can enforce TLS and SMTP AUTH for all connections. This excludes some botnet clients and prevents disclosure of plain-text SMTP AUTH credentials.

• You can severely rate limit all connecting clients, so that when a user account is compromised, the damage is limited. A heavily rate limited connection is not much use to junk senders, and having these limits can deter further attempts.

If you’re not already using this configuration, client MUAs need to be modified to reflect the host, port, and TLS settings.

The HAT and RAT configuration to support SMTP submission is fairly simple:

1. Add the listener to one of your IP listeners on port 587. Choose the public listener type.

2. Modify the HAT and delete all the included sender groups, leaving only the ALL group.

3. Modify the ACCEPTED policy, turning on TLS and SMTP AUTH and making them both Required. Lower connection and rate limits to 1 connection per client IP, one message per connection, and no more than 25–100 recipients per hour.

4. Configure the RAT to be empty (that is, the only entry is “All Other Recipients” with a value of Reject). This means that any connecting sender that fails to SMTP AUTH has no sending privileges whatsoever.

In this private submission listener, when a client connection is made to port 587, the client will be required to use TLS for encryption of credentials, and must authenticate to send any messages. A client that does not authenticate will have an accept mail flow behavior applied, but the RAT check will prevent them from sending to any recipient. A client that authenticates properly will skip the RAT check because it gets elevated from accept to relay behavior. This works without a RELAY group because of the privilege elevation of SMTP AUTH. The rate limits in Step 3 will limit the abuse of malicious senders who steal valid credentials.

Email “Front End” to Complex Internal Organizations

Another class of email architecture one finds is the front-end service provider. In these environments, the focus is on email hygiene and local message delivery, not the mailbox storage directly. For some organizations, that’s all there is to it: message acceptance, security scanning, and delivery; the end users are part of another organization or part of a separate division of an organization.

Many state and local governments use this architecture to provide a consistent front-end email service across the many different government divisions. Some large multinational and conglomerate commercial companies use this architecture, with global email gateway services providing a veneer of single-brand identity to many different divisions. Some business-email service providers and domain registrars also fall into this category, where clean messages are delivered to each client’s specified mail host.

These environments often have to deal with every single challenge that could affect an email environment: external threats, internal threats, bad sender policies, uncertain reliability of next-hop hosts, and extreme variations in message volumes.

• Keep restrictive policies for both incoming and outgoing mail connection and rate limits.

• Use LDAP group policies to allow divisions or clients to define their own restrictions and filters. Predefine policies for aggressive, conservative, or moderate spam filters and allow users a means of setting their preferences in the LDAP directory.

• Segment traffic. It’s often not possible to provide every client or division with a separate VG for delivery, but if you have a modest number, it’s recommended. This prevents a single group’s email traffic behavior from impacting others.

• If you handle a lot of domains that are continually updated, the RAT may present capacity or administrative limits. The solution is to use an open RAT, combined with LDAP accept queries on the domain portion of the address, or LDAP or SMTP call-ahead on the entire address.

The last of these warrants more attention, and certainly needs to come with very strong warnings about the configuration. An open RAT is one where the default policy is ALL ACCEPT, meaning that the ESA will allow sending to any destination domain. This creates an open relay configuration, which by itself is extremely bad: It allows your MTA to be used by anyone to send mail anywhere.

To prevent the open relaying, the domain verification can be done via LDAP. Test and enable an LDAP accept query. When an SMTP client connects to deliver mail, the destination domain passes the RAT and then must go to LDAP for verification. As new domains are provisioned and added to LDAP, the ESA automatically accepts those messages. When you assign LDAP accept queries to the listener, make sure that you choose the option to temporarily reject mail by issuing a 451 SMTP response code. Allowing mail in creates an open relay if LDAP were unavailable.

Summary

This chapter discussed the best way to run a secure, reliable gateway email environment with the ESA. Starting with the first line of defense, the HAT, we discussed connection controls and rate limits. I advocate strong rate limits, but I hopefully gave you enough information to judge the risks and rewards of a lock-down configuration. Because tight controls often require exceptions, we discussed creating specific groups for legitimate large senders, like major webmail providers.

Email security encompasses the sending of outgoing mail, and you need to take into account your policies for filtering and delivering messages. Nothing can affect the reception of your messages at other organizations more than your outgoing configuration. We also discussed the problem of bounce backscatter and how to avoid being affected by it, but we also discussed how to avoid being part of the problem.

Architecture has been a focus of this book, and this chapter discussed recommendations for different kinds of environments and the challenges each can face.

In the next chapter, we close with a few advanced topics: new trends in email authentication and filtering concepts.