Email Services Deployment. Administrator Guide

Email Services Deployment Administrator Guide

Email Services Deployment Guide Documentation version: 1.0 Legal Notice Legal Notice Copyright 2013 Symantec Corporation. All rights reserved. Symantec, the Symantec Logo, the Checkmark Logo and are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners. No part of this document may be reproduced in any form by any means without prior written authorization of Symantec Corporation and its licensors, if any. Symantec Corporation 350 Ellis Street Mountain View, CA 94043 http://www.symantec.com Clients are advised to seek specialist advice to ensure that they use the Symantec services in accordance with relevant legislation and regulations. Depending on jurisdiction, this may include (but is not limited to) data protection law, privacy law, telecommunications regulations, and employment law. In many jurisdictions, it is a requirement that users of the service are informed of or required to give consent to their email being monitored or intercepted for the purpose of receiving the security services that are offered by Symantec. Due to local legislation, some features that are described in this documentation are not available in some countries. Configuration of the Services remains your responsibility and entirely in your control. In certain countries it may be necessary to obtain the consent of individual personnel. Symantec advises you to always check local legislation prior to deploying a Symantec service. You should understand your company s requirements around electronic messaging policy and any regulatory obligations applicable to your industry and jurisdiction. Symantec can accept no liability for any civil or criminal liability that may be incurred by you as a result of the operation of the Service or the implementation of any advice that is provided hereto. The documentation is provided "as is" and all express or implied conditions, representations, and warranties, including any implied warranty of merchantability, fitness for a particular purpose or non-infringement, are disclaimed, except to the extent that such disclaimers are held to be legally invalid. Symantec Corporation shall not be liable for incidental or consequential damages in connection with the furnishing, performance, or use of this documentation. The information that is contained in this documentation is subject to change without notice. Symantec may at its sole option vary these conditions of use by posting such revised terms to the website.

Technical support If you need help on an aspect of the security services that is not covered by the online Help or administrator guides, contact your IT administrator or Support team. To find your Support team's contact details in the portal, click Support > Contact us.

Contents Technical support... 3 Chapter 1 About deploying Email Services... 7 Deploying Email Services step-by-step... 7 Attend training on the portal... 13 Configuring the cloud Email Services... 13 Chapter 2 Configuring your mail setup... 15 Pre-implementation checks... 15 Technical checks... 17 Redirecting inbound email traffic to the Email Services infrastructure... 18 Important notes on changing MX records... 20 Restricting your email traffic... 21 About configuring outbound email traffic (optional)... 22 Testing outbound mail... 22 Cloud security services IP ranges... 24 Restricting open relay... 25 Chapter 3 Configuring MS Exchange... 27 Configuring Microsoft Exchange 2003 for inbound mail... 27 Configuring Microsoft Exchange 2003 for outbound mail... 28 Configuring Microsoft Exchange 2007 and 2010 for outbound mail... 30 Chapter 4 Configuring your public hosted cloud services... 33 Configuring Google Apps Email for inbound mail... 33 Configuring Google Apps Email for outbound mail... 34 Configuring Microsoft Office 365 for inbound mail... 35 Configuring Microsoft Office 365 for outbound mail... 35

6 Contents

Chapter 1 About deploying Email Services This chapter includes the following topics: Deploying Email Services step-by-step Attend training on the portal Configuring the cloud Email Services Deploying Email Services step-by-step You should have received a confirmation email that contains the information that you need to deploy Email Services: The default and backup MX record data The default mail route The following phases are involved in deploying Email Services: Pre-provisioning phase: you have probably already completed these steps. Provisioning phase: your Email Services supplier performs these steps. Implementation phase: you carry out these steps. Step Table 1-1 Pre-provisioning phase Further information 1. Complete a provisioning form. Send the form to your account manager.

8 About deploying Email Services Deploying Email Services step-by-step Step Table 1-1 Pre-provisioning phase (continued) Further information 2. 3. Attach your signed contract along with the completed provisioning form. Attach a list of valid email addresses for the Address Registration functionality along with the completed provisioning form. For further information, see the Help on Address Registration. 4. To ensure that your account is set up as soon as possible, we recommend steps to take before you submit your technical details. See Pre-implementation checks on page 15. Table 1-2 Provisioning phase 1. 2. 3. Step Technical checks are carried out on the IP address and domain names you have provided in your provisioning form. These checks ensure that we can provision your organization for Email Services. If a check fails for any reason, we inform you of the reason by email. You must inform us when you have resolved the issues, so that we can recheck your information. Your account is provisioned on the Email Services infrastructure. We send you a confirmation email that provides your portal login details. The email also contains the data and information that you need to change your MX records and to lock down your firewall. Warning: Ensure that this email is not detected as spam or junk email. The email contains important information. Further information See Technical checks on page 17. 4. We send your cleaned and uploaded address list as a CSV attachment to your confirmation email for you to check. For further information, see the Help on Address Registration.

About deploying Email Services Deploying Email Services step-by-step 9 Table 1-3 Implementation phase Step 1. Check your address lists 2. Review your inbound and your outbound routes for email traffic Description Review, modify, and save your address list for each of your domains. In the portal, click Services > Email Services > Platform. Your list of valid email addresses ensures that you only receive email for legitimate users in each domain in your organization. Email Security drops any emails that are sent to addresses on your domain that are not registered for your organization. You can manage this list yourself in the portal or use the Synchronization Tool. Review your inbound and your outbound email routes for your domains. In the portal, click Services > Email Services > Inboundroutes and Outbound routes. Further Information 3. Check your service configuration settings When Email Services are fully deployed, the AntiVirus and AntiSpam services are automatically active. They are configured with default settings. Your inbound email (and outbound email, if provisioned) automatically pass through the cloud security services scanners. To customize the settings for AntiVirus and AntiSpam, make the necessary configuration changes before you change your MX records. See Attend training on the portal on page 13. See Configuring the cloud Email Services on page 13. In the portal, click Services > Email Services.

10 About deploying Email Services Deploying Email Services step-by-step Step Table 1-3 Description Implementation phase (continued) Further Information 4. Setting up Spam Quarantine Spam Quarantine enables your organization's users to view the emails that the Email AntiSpam service has detected as spam. These emails are viewable in a portal called Spam Manager. If you have Spam Quarantine enabled, Quarantine the mail is an action in your Email AntiSpam Detection Settings page of the portal. If Spam Manager is not enabled and you want it to be, contact: Global Client Service Initiatives For Spam Quarantine, you must have Address Registration enabled and active. The URL for Spam Manager is provided in your welcome email. It has the following format: https://spammanager-xxx.messagelabs.com/login.xsp Note: If you are an existing customer adding a new domain, check your current Spam Manager URL. Use the same URL for your new domain.

About deploying Email Services Deploying Email Services step-by-step 11 Step Table 1-3 Description Implementation phase (continued) Further Information 5. Redirect your inbound email traffic to the Symantec.cloud infrastructure. Complete the following MX record changes within five working days of receiving your confirmation email. It may take up to 24 hours for MX record changes to result in full propagation. Make sure that any previous MX records in place are NOT removed until the change to Symantec.cloud has fully propagated. When the records are propagated, ensure that there are no back-up MX records left in place. If an external organization (e.g. your ISP) manages your MX records, ensure that this information is passed on to them. Define the MX records for your domains. These are provided in you Welcome email. They use the following format: See Redirecting inbound email traffic to the Email Services infrastructure on page 18. Lowest MX preference (default mail route): MX 10 clusterx.xx.messagelabs.com Second MX preference (back-up mail route): MX 20 clusterx.xx.messagelabs.com Note: When Email Services are provisioned and before your MX records are changed, Symantec.cloud may process some of your email. Emails that are sent to your domain(s) by other Email Services customers who are provisioned on the same infrastructure as you are processed. The portal Dashboard and reports may show that email has been received before the MX change.

12 About deploying Email Services Deploying Email Services step-by-step Step Table 1-3 Description Implementation phase (continued) Further Information 6. Configure your SMTP server or public hosted cloud service for inbound traffic. 6. Redirect your outbound mail traffic (optional) Note: We recommend that you make this redirection the first of the technical changes of the implementation process. You can perform it immediately. And it provides a good test of your client-side technical changes; outbound email traffic is generally quieter than inbound email traffic. Allow email to come into your organization only through the Email Services infrastructure by defining an allow list in your firewall or your mail server. Or for public hosted cloud services, you configure inbound traffic in the portal. Configure your organization s SMTP server to have your outbound email scanned. Use your assigned cluster host name rather than a single IP to ensure security and resiliency. The cluster host name is provided in your Welcome email. It uses the following format: Relay outbound mail traffic to: clusterxout.xx.messagelabs.com Relay outbound mail traffic to: clusterxout.xx.messagelabs.com Reduce TTL (time to live) and DNS cache to its lowest possible setting (recommended 5-15 minutes). Configure your public hosted cloud service for outbound traffic in ClientNet. See Configuring Microsoft Exchange 2003 for inbound mail on page 27. See Configuring Google Apps Email for inbound mail on page 33. See Configuring Microsoft Office 365 for inbound mail on page 35. See About configuring outbound email traffic (optional) on page 22. See Configuring Microsoft Exchange 2003 for outbound mail on page 28. See Configuring Google Apps Email for outbound mail on page 34. See Configuring Microsoft Office 365 for outbound mail on page 35. 7. Restrict SMTP traffic We recommend that you lock down port 25 SMTP traffic to and from your Internet gateway to the following IP ranges: See Restricting your email traffic on page 21. Symantec.cloud IP Ranges Locking down port 25 prevents spam and viruses being sent directly to or from your mail server. It also enables us to balance traffic across the infrastructure if Internet conditions require it. For example, during mass mailer outbreaks, dictionary attacks, and denial-of-service attacks. Warning: If you do not accept email from these IP ranges, there is a risk of partial email failure.

About deploying Email Services Attend training on the portal 13 Caution: Once you have deployed your Email Services, your mail is scanned for viruses and spam. The AntiVirus and AntiSpam services are enabled and default settings are in place. The default settings include email disclaimers and email alert notifications. If you do not want to use the default disclaimer or alert notifications, change the necessary settings in the portal before you change your MX records. The Image Control and Content Control services are not active until you enable them in the portal Services pages. See Configuring the cloud Email Services on page 13. Attend training on the portal The portal gives you direct access to your account configuration. It lets you review the performance of the Email Services for your business. We recommend that you take advantage of the live WebEx sessions, which last for approximately 30 minutes each, to help you use the portal to optimize your services. For timings and access details, see Live Webinar: Cloud security services. The WebEx session covers: Service Overview: which services are included and how emails are scanned Service Implementation: service defaults and portal configurations Service Optimization: portal optimization, account administration, and service continuance Tools and Resources: online self-service tools and getting support Portal Demonstration: portal URL, login requirements, and navigation tips Questions and Answers See Configuring the cloud Email Services on page 13. Configuring the cloud Email Services When Email Services are fully deployed, the AntiVirus and AntiSpam services are automatically active. They are configured with default settings. Your inbound email (and outbound email, if provisioned) passes through the cloud security services infrastructure. To customize the settings for AntiVirus and AntiSpam, make the necessary configuration changes before you change your MX records.

14 About deploying Email Services Configuring the cloud Email Services Note: To use the Image Control and Content Control services, you must first configure and enable them in the portal. For further information on Email Services, see Help on cloud security services. Note: We support public hosted cloud email services from Google Apps and Microsoft Office 365. To scan inbound mail on a public hosted cloud service, you must configure an inbound email route in the portal. If your organization needs to scan your outbound mail from a supported public hosted cloud service you must also configure an outbound route. See Redirecting inbound email traffic to the Email Services infrastructure on page 18.

Chapter 2 Configuring your mail setup This chapter includes the following topics: Pre-implementation checks Technical checks Redirecting inbound email traffic to the Email Services infrastructure Important notes on changing MX records Restricting your email traffic About configuring outbound email traffic (optional) Testing outbound mail Cloud security services IP ranges Restricting open relay Pre-implementation checks Before we complete the setup of Email Services, we perform certain tests. To ensure that your account is set up as soon as possible, we recommend steps that you can take before you submit your technical details.

16 Configuring your mail setup Pre-implementation checks Table 2-1 Check Pre-implementation checks Test Preparation Connectivity Domain check Open relay The connectivity check is an important part of the cloud security services setup. It checks that we can successfully deliver mail to your specified IP address. When performing this test, we try to deliver a test email through port 25 to the postmaster address at the IP address you have provided. The domain check tests that the domains you want to use with the cloud security services are registered. The cloud security services performs a DNS check to ensure that the domain is registered. The open relay test concerns the IP addresses you want to send outbound mail from. An open relay server is an SMTP server configured for people outside of your organization to send mail through. Open relay is commonly exploited by spammers and therefore presents a security threat. To minimize the chance of this test failing, ensure that you allow the cloud security services IP ranges through your security device, such as your firewall. These IP ranges vary according to region. They can be found at: Cloud security services IP Ranges. Also ensure that your mail server is configured to relay for all domains you want to use. If a domain has not been configured but you want to proceed with the setup, inform us when completing the provisioning form. Ensure that any domains you want to use are valid and registered. Ideally, they should also have MX records present. Ensure that you have configured your mail server so that it only accepts email from local addresses. If you are unsure whether your IP is an open relay, there are several Web-based tools you can use to check this, e.g. www.abuse.net/relay.html.

Configuring your mail setup Technical checks 17 Table 2-1 Pre-implementation checks (continued) Check Test Preparation Blacklists When you add a new IP address to the Email Services infrastructure, we test to ensure that the IP address is not blacklisted on CBL, SBL, Spamcop, or DSBL. You can check whether your IP address has been blacklisted or not with the following sites: CBL (http://cbl.abuseat.org/) SBL (http://www.spamhaus.org/sbl/) Spamcop (http://spamcop.net/bl.shtml) DSBL (http://dsbl.org/main) Note: If your IP address is listed, we recommend that you find out why your IP address was blacklisted to prevent it happening again. See Technical checks on page 17. Technical checks The IP addresses or mail hosts and domain names that you have provided to us must pass a series of technical checks before you are provisioned with our Email Services. If the technical checks all complete successfully, the Provisioning Team sets up your domains on the cloud security services infrastructure. We then send a confirmation email that provides your portal logon and the data and information that you need to change your MX records and to lock down your firewall. If a test has failed, you are asked to make the changes necessary to remedy the issue so that the services can be activated. The technical checks that are performed depend on the information provided, but are summarized in the following table. Table 2-2 Technical checks Domain checks: Checks that the domain is registered with the Domain Name Server (DNS) Checks that the Email Services are not already scanning the domain

18 Configuring your mail setup Redirecting inbound email traffic to the Email Services infrastructure Table 2-2 Technical checks (continued) IP checks: Checks that open relay is not allowed Checks that your IP addresses are from valid ranges Checks that your IP addresses are not blacklisted Checks connectivity with the cloud Email Services infrastructure Warning: You must ensure that your SMTP server does not allow open relay. If it does, your server can be used as a spam gateway. Most current SMTP servers and firewalls allow the restriction of SMTP relay in the following ways: by IP number (so you only accept mail from our IP addresses) or by domain (so you reject email that is destined for domains other than your own). See Pre-implementation checks on page 15. See Restricting open relay on page 25. Redirecting inbound email traffic to the Email Services infrastructure To redirect your inbound email traffic to the Email Services infrastructure, you must change your MX records. You must change your MX records for both an SMTP server and a public hosted cloud service such as Google Apps Email, or Microsoft Office 365. An MX record is a type of resource record in the Domain Name System (DNS) that defines how email is routed. MX records point to the servers that should receive email and define their priority relative to each other. Your MX records need to route your inbound email through the cloud security services infrastructure, where Email Services scan the emails. The clean emails continue on to your email recipients. To route your email through the cloud security services infrastructure, your MX records must change to the values that we give you to ensure that all of your email is scanned. They are used as pointers to where your emails are delivered. To route your email through Email Services, change the primary and the secondary MX records for your domains to the MX records that we provide you with. These are in your confirmation email from us. Your New Customer confirmation email contains the exact MX information that you should use. Caution: Check that the confirmation email is not delivered to your spam folder. This email contains very important information.

Configuring your mail setup Redirecting inbound email traffic to the Email Services infrastructure 19 First, identify who hosts your domains; that is, the person or organization that is responsible for maintaining your organization s MX records or DNS settings. Your Internet service provider (ISP) may be responsible for your MX records. Typically, each provider supplies an online form to make changes. Or you may have to notify them that you require a change to your MX records. A typical set of MX records before you modify them to use Email Services may look like the examples in the following table. Table 2-3 MX records example Mail route Primary (lowest) MX preference (default) Second MX preference (back-up) MX record MX 10 mailhost.domain.com MX 20 relay.isp.com The new MX record entries that you should use are in the format that is shown in the following table. Table 2-4 MX records example Mail route Primary (lowest) MX preference (default mail route) Second MX preference (back-up mail route) New MX record MX 10 clusterx.xx.messagelabs.com MX 20 clusterxa.xx.messagelabs.com Ensure that these changes are completed within five working days of receiving your confirmation email and that no back-up MX records remain in place. Note: As soon as the MX record changes have been made and have propagated, the Email Services start scanning the emails that your domain receives from external senders. When Email Services are fully deployed, the AntiVirus and AntiSpam services are automatically active. They are configured with default settings. Your inbound email (and outbound email, if provisioned) passes through the Email Services infrastructure. To customize the settings for AntiVirus and AntiSpam, make the necessary configuration changes in the portal before you change your MX records. See Restricting open relay on page 25.

20 Configuring your mail setup Important notes on changing MX records Important notes on changing MX records Use only the MX records specified in your New Customer confirmation email so that we can scan all of the email destined to your network. The presence of non-cloud security services entries in your MX records, e.g. mailhost.your-domain.com or isp-relay.your-domain.com is a security risk. Spammers, virus writers, and fraudsters often target back-up MX record entries in an attempt to bypass the cloud Email Services. In this way, spam or other malicious content can be delivered to your organization directly. Your MX records should never include an entry for your mail server or any type of mail relay. It can take up to 24 hours for MX record changes to result in full propagation. However, you should allow 72 hours for changes to fully propagate across the Internet. Full propagation means that the cloud Email Services can scan all email that your domain receives from external sources. Once your organization is provisioned with cloud Email Services, it is possible that we could process some of your email before you have changed your MX records. This is the case if another cloud Email Services customer is provisioned on the same cluster as your organization. An email that is sent to one of your domains by another customer passes through the scanners on its way out from the sending customer. We identify that your domains are provisioned on our system and route those emails through your inbound policies and onto your provisioned gateways. So, an email that is sent from another of our clients to you on your cluster means that your service configurations are applied. You may experience the following: Your email disclaimers are applied. See Services > Email Services > Email disclaimers. Your AntiSpam detection settings filter spam The inbound Content Control rules that you have defined are applied Your inbound Image Control settings are applied Address Registration is operational. Your up-to-date address list must be applied. Otherwise, an email that is sent from another client on your cluster is blocked because it is not found in your address list. Inbound email size restrictions are applied. See Services > Email Services > Anti-Virus > Virus Settings. Your dashboard and reports may show that email has been received for you An email that is sent to you from another of our clients that is on the same cluster as you is delivered to your provisioned Mailhosts.

Configuring your mail setup Restricting your email traffic 21 Caution: If you have asked us to send email to a Mailhost that is not yet ready to accept mail, contact us immediately. See Redirecting inbound email traffic to the Email Services infrastructure on page 18. See Restricting open relay on page 25. Restricting your email traffic To ensure that your inbound emails do not bypass Email Services, you must restrict the IP addresses you allow email traffic from to the cloud security services IP ranges. By allowing emails to be received only from our IP ranges, you prevent spammers bypassing the scanning service and sending mail directly to your server s IP address. Only port 25 traffic needs to be "locked down" to accept the cloud security services IP addresses. Caution: The mail server (or firewall) configuration changes given here should be completed only after full MX record propagation is complete. Allow 72 hours from your MX records having been changed for full propagation across the Internet. Depending on your organization s IT setup, you must define the IP ranges to use in your mail server, firewall, or public cloud hosted email service, or any combination of these. The IP ranges that you need to configure in the allow list of your firewall, mail server, or public cloud hosted email service are listed in cloud security services IP ranges. This document is also available from a link in your welcome email. Note: Due to the diverse range of mail servers and firewalls in use, we cannot provide instructions or support for the configuration of IP address allow lists in firewalls or mail servers. Contact your IT department or IT consultant for assistance. However, basic instructions are provided for Microsoft Exchange 2003. See Redirecting inbound email traffic to the Email Services infrastructure on page 18. See Configuring Microsoft Exchange 2003 for inbound mail on page 27. See Configuring Microsoft Exchange 2007 and 2010 for outbound mail on page 30.

22 Configuring your mail setup About configuring outbound email traffic (optional) See Configuring Google Apps Email for inbound mail on page 33. About configuring outbound email traffic (optional) All of our clients use Email Services for inbound scanning, and most also use the services for outbound scanning. Outbound scanning is included with your service at no additional charge, but using this feature is optional. We advise that you send your outbound email through the cloud Email Services infrastructure to ensure that no viruses are sent out from your network. You can then be sure that we have scanned any email that is sent from your organization. One email threat is the exploitation of domains to spoof email to appear as if it is sent from your organization. Outbound scanning also helps enforce email policies if you use the Image Control and Content Control services. To have your outbound email scanned, you configure your organization's SMTP server or your public hosted cloud email service to send email through the cloud security services infrastructure. To do so, you define the IP ranges for outbound email traffic in your mail server, depending on your mail server configuration. This involves creating a mail route, for example in the following format: clusterxout.xx.messagelabs.com Refer to your New Customer confirmation email for the exact outbound Mailhost information to use. Note: Due to the diverse range of mail servers in use, we cannot provide instructions or support for the configuration of IP addresses in mail servers. Contact your IT department or IT consultant for assistance. However, basic instructions are provided for Microsoft Exchange 2003, 2007, and 2010, and for the public hosted cloud services we support. See Configuring Microsoft Exchange 2007 and 2010 for outbound mail on page 30. Testing outbound mail See Configuring Microsoft Exchange 2003 for outbound mail on page 28. See Configuring Google Apps Email for outbound mail on page 34. You can spoof the sending of an email using telnet to test that it is correctly routed through Email Services.

Configuring your mail setup Testing outbound mail 23 To test outbound mail 1 Type the following command using the outbound mail route provided: telnet clusterxout.xx.messagelabs.com 25 If the connection is accepted, the remote server responds: Trying 195.245.230.67... (remote server IP) Connected to clusterx.xx.messagelabs.com. Escape character is '^'. 220 server-4.tower-50.messagelabs.com ESMTP 2 Type a valid helo command (helo and a word of more than five characters): helo mail.customer.com The remote server responds that the SMTP conversation has started: 250 server-4.tower-50.messagelabs.com 3 Type in a valid email address at your domain: mail from: example@domain.com The remote server responds: 250 OK 4 Type an external email address here: rcpt to: example@domain.com 250 OK 5 Then type: data This instruction tells the remote server that data is due to be received. The remote server responds: 354 go ahead

24 Configuring your mail setup Cloud security services IP ranges 6 Type the subject and body of the email. Email Services must have an email with a body or it gives a 550 error: subject: testing testing testing To finish, enter:.. (period, return, period, return) The remote server responds: 250 ok 1176493466 qp 7506 server-4.tower- 50.messagelabs.com!1176493400!6015990!1 This 250 OK message means that an email has been successfully transferred from the sending mail server to the recipient mail server. 7 Type the quit command to close the connection: quit The remote server responds: 221 server-4.tower-50.messagelabs.com Connection closed by foreign host. See About configuring outbound email traffic (optional) on page 22. Cloud security services IP ranges We recommend that you lock down the traffic to and from your Internet gateway to the IP ranges for your region. The IP address ranges are available from the following link: Cloud security services IP ranges If you are unsure of the region to select, refer to the email you received when you were first provisioned with the service. Whenever you make temporary or permanent network configuration changes involving IP restrictions, refer to the latest version of this document. The IP address information is updated regularly. See Restricting your email traffic on page 21. See Configuring Microsoft Exchange 2003 for inbound mail on page 27. See Configuring Microsoft Exchange 2007 and 2010 for outbound mail on page 30.

Configuring your mail setup Restricting open relay 25 Restricting open relay For historical reasons, many SMTP mail servers accept email for domains other than their own and forward it on to the intended recipient. Third-party relay, also known as open relay or insecure relay, is when a mail server routes email for anybody in the world. An open relay is any computer that accepts email for any domain and forwards it regardless of who the sender is or what IP address the email is sent from. Spammers hunt for and abuse these servers to try and cover their tracks. When spammers locate such a computer they can use it as a free distribution service for their junk email. This process often leads to the client s IP address or domain being blacklisted. There is even a risk of our infrastructure being blacklisted if clients' email is sent outbound through us. You must ensure that your SMTP server does not allow open relay. If it does allow open relay, your server can be used as a spam gateway. Most current SMTP servers and firewalls allow the restriction of SMTP relay in the following ways: By IP address: so you only accept mail from our IP address ranges By domain: so you reject email that is destined for domains other than your own You can check if your mail server is an open relay by using a network tool that is provided by Network Abuse Clearinghouse. This tool automatically tests your mail server for relay security. You must register with them to be able to perform these tests, but the registration is straightforward. Open relay checker

26 Configuring your mail setup Restricting open relay

Chapter 3 Configuring MS Exchange This chapter includes the following topics: Configuring Microsoft Exchange 2003 for inbound mail Configuring Microsoft Exchange 2003 for outbound mail Configuring Microsoft Exchange 2007 and 2010 for outbound mail Configuring Microsoft Exchange 2003 for inbound mail Typically, you allow email to come into your organization only through the Email Services infrastructure by defining an allow list in your firewall. Depending on your organization s mail setup, you may want to configure the allow list in your mail server instead. Due to the numerous mail servers in use, we cannot provide instructions for all of these. The IP ranges to allow are available from the following link: Cloud security services IP ranges The following procedure provides the steps for defining IP address allow lists in Microsoft Exchange 2003. Connection filtering lets you create global accept and deny lists. Use these lists to always accept or always reject the mail that is sent from specific IP addresses, regardless of whether you use a block list service provider. Any IP address that appears on the global accept list is automatically accepted, and any connection filtering rules are bypassed.

28 Configuring MS Exchange Configuring Microsoft Exchange 2003 for outbound mail To create a global accept list 1 Select Start > All Programs > Microsoft Exchange > System Manager. 2 In the console tree, expand Global Settings, right-click Message Delivery, and then click Properties. 3 Click the Connection Filtering tab. 4 Click Accept. The Accept List opens. 5 Click Add. 6 In IP Address (Mask), click Group of IP Addresses and insert the IP ranges provided and click OK. To apply the connection filter to the appropriate SMTP virtual servers 1 Select Start > Programs > Microsoft Exchange > System Manager. 2 In the console tree, expand Servers > servername > Protocols > SMTP, right-click the SMTP virtual server on which to apply the filter, and then click Properties. 3 On the General tab, click Advanced and select the IP address to apply the filter for, and then click Edit. 4 In Identification, select the Apply Connection Filter checkbox to apply the connection filter that you created previously. See Restricting your email traffic on page 21. Configuring Microsoft Exchange 2003 for outbound mail Use the following procedure to configure Exchange 2003 to send Internet mail. When you configure an Exchange server to send Internet mail, the Internet Mail Wizard configures the selected server as an outbound bridgehead server. It creates a connector on this server to send mail to the Internet addresses you specify. To run Internet Mail Wizard and configure your server to send Internet mail 1 Open Microsoft Exchange System Manager. 2 In the console tree, right-click your Exchange organization and click Internet Mail Wizard > Next. 3 On the Prerequisites for Internet Mail page, read the requirements. Ensure that you have completed the tasks listed, and then click Next. Your server must satisfy these conditions:

Configuring MS Exchange Configuring Microsoft Exchange 2003 for outbound mail 29 You must have registered your company's SMTP domain or domains with an Internet registrar. The Exchange server that you want to configure for Internet email has an Internet IP address assigned to it. DNS is correctly configured. Your DNS server must have a mail exchange (MX) record pointing to the Internet IP address of your Exchange server. Your DNS server must also be able to resolve external Internet names. 4 In the Server Selection page, from the Server list, select the Exchange server to used for outbound mail delivery and click Next. The Internet Mail Wizard checks your server configuration. When the check is complete, the results are displayed under Report. If your server meets the necessary conditions, click Next. You cannot run Internet Mail Wizard if any of the following conditions exist on your server: Your server is part of a Microsoft Windows cluster. Your server is part of a network load-balancing cluster. Your server has multiple network interface cards that are configured with separate networks in which IP routing is enabled between the networks. Note: This page displays only if your SMTP virtual server is configured to allow open relay. If your SMTP virtual server does not allow open relay, this page does not display. 5 On the Internet E-mail Functions page, select the Send Internet e-mail checkbox, and then click Next. 6 On the Outbound Bridgehead Server page, under SMTP virtual server, ensure that the Exchange server and the SMTP virtual server that is designated as the bridgehead are displayed. Click Next. When you use the Internet Mail Wizard to configure your Exchange server to send outbound Internet mail, the server cannot already be configured as a bridgehead for any SMTP connectors in the Exchange organization. 7 If the Open Relay Configuration page displays, your server is configured to allow open relay. With open relaying, external users can use your server to send unsolicited commercial mail. Open relay means that other legitimate servers can block mail from your Exchange server. To secure your server, click Disable open relay, and then click Next.

30 Configuring MS Exchange Configuring Microsoft Exchange 2007 and 2010 for outbound mail 8 On the Outbound Mail Configuration page, click Route all mail through the following smart host and enter the default outbound mail route provided (for example, clusterxout.xx.messagelabs.com). Then, click Next. The default outbound mail route is provided in your welcome email. 9 On the Outbound SMTP Domain Restrictions page, select Allow delivery to all e-mail domains. Then, click Next. 10 Review the configuration options that you selected and where the configuration settings are saved. Then, click Next to start the configuration. 11 When the Completing the Internet Mail Wizard page displays, select the View detailed report. 12 When this wizard closes, select the checkbox to view the log file, and then click Finish. See Restricting open relay on page 25. Configuring Microsoft Exchange 2007 and 2010 for outbound mail Send Connectors allow Exchange Server to route all outbound email through another SMTP server. To configure a send connector 1 Open the Exchange Management Console and click Organization Configuration > Hub Transport > Send Connectors. 2 Right-click in the list in the center pane and select New Send Connector. 3 In the wizard, type a name for the connector and from the Selecttheintended use for this Send Connector drop-down list, select Custom. Click Next. 4 In the Address Space page, click Add. Enter * as the domain, and check Include all subdomains. 5 Click OK, then click Next. 6 In the Network settings page, select the Route mail through the following smart hosts button, and click Add. 7 In the Add smart host page, select Fully qualified domain name (FQDN), and enter your assigned cluster host name for outbound email traffic. Your cluster host name is provided in your welcome email. The cluster host name is in the following format: clusterxout.xx.messagelabs.com 8 Click OK, then click Next.

Configuring MS Exchange Configuring Microsoft Exchange 2007 and 2010 for outbound mail 31 9 Under Configure smart host authentication settings, select None. 10 On the Source Server page, click Add and select your Exchange Server that runs the hub transport role. 11 Click OK, then click Next.. A configuration summary page is displayed. 12 Review your configuration summary. Then, to confirm, click New. The SMTP Send Connector is created.

32 Configuring MS Exchange Configuring Microsoft Exchange 2007 and 2010 for outbound mail

Chapter 4 Configuring your public hosted cloud services This chapter includes the following topics: Configuring Google Apps Email for inbound mail Configuring Google Apps Email for outbound mail Configuring Microsoft Office 365 for inbound mail Configuring Microsoft Office 365 for outbound mail Configuring Google Apps Email for inbound mail Note: The information given here is for guidance only. For the current advice from Google, refer to the user documentation for Google Apps Email. By defining a list of IP addresses in the Google Apps Email inbound gateway, you allow email to come into your organization only through the Email Security service. The allowable IP ranges are available from the following link: Cloud security services IP ranges. In this document see the table for All Regions and the table for South Africa only. Note: You must also configure the Email Security service to forward inbound email to Google Apps Email. See Redirecting inbound email traffic to the Email Services infrastructure on page 18.

34 Configuring your public hosted cloud services Configuring Google Apps Email for outbound mail The following procedure provides the steps for defining IP address lists in Google Apps Email. To configure Google Apps Email for inbound mail 1 Log in to your Google Apps Email administrator console. 2 Select Settings > Email > General Settings. 3 In Inbound Gateway type the Cloud security services IP ranges as a comma-separated list. 4 Select Only let users receive email from the email gateways listed above. See Redirecting inbound email traffic to the Email Services infrastructure on page 18. See Restricting your email traffic on page 21. Configuring Google Apps Email for outbound mail Note: The information given here is for guidance only. For the current advice from Google, refer to the user documentation for Google Apps Email. When you configure Google Apps Email to send email to the Internet, you can configure an outbound gateway to send mail directly to the Internet addresses you specify. In this case email is sent to the Email Security service. Note: You must also configure the Email Security service to forward outbound email to Google Apps Email. See About configuring outbound email traffic (optional) on page 22. To configure Google Apps Email for outbound mail 1 Log in to your Google Apps Email administrator console. 2 Select Settings > Email > General Settings. 3 In Outbound Gateway type the host name provided by the cloud security services, typically in the format clusterxout.eu.messagelabs.com.

Configuring your public hosted cloud services Configuring Microsoft Office 365 for inbound mail 35 Configuring Microsoft Office 365 for inbound mail Note: The information given here is for guidance only. For the current advice from Microsoft, refer to the user documentation for Microsoft Office 365. There are currently no special recommendations, in addition to the standard recommendations provided by Microsoft, for setting up Microsoft Office 365 to accept inbound mail from the cloud security services. See Restricting your email traffic on page 21. Configuring Microsoft Office 365 for outbound mail Note: The information given here is for guidance only. For the current advice from Microsoft, refer to the user documentation for Microsoft Office 365. When you configure Microsoft Office 365 to send email to the Internet, you can configure an outbound gateway to send mail directly to the Internet addresses you specify. In this case email is sent to the Enail Security service. Note: You must also configure the Email Security service to forward outbound email to Microsoft Office 365. See About configuring outbound email traffic (optional) on page 22. To configure Microsoft Office 365 for outbound mail 1 Log in to your Microsoft Office 365 Admin Console. 2 Select Administration > Company > Outbound Connector. 3 In Outbound Connectors add a new connector with an appropriate name and description to forward your outbound emails from designated domains, typically *.*, to the Email Security.Service. 4 Select Deliver all messages to the following destinations. 5 Type the fully-qualified domanin name as provided by the cloud security services, typically in the format clusterxout.eu.messagelabs.com. 6 Select Opportunistic TLS. 7 Click Save. 8 Set the connector to Enforce.

36 Configuring your public hosted cloud services Configuring Microsoft Office 365 for outbound mail