An update to Important notice for Office 365 email customers who have configured connectors
Since we posted this blog post, we have received positive responses from many of our customers, who have proceeded with changing their connectors (as per instructions in the post), thereby protecting their email/domain reputation. However, we are also aware of customers who are either in the midst of making this change or need some additional time to complete their changes. We understand a change like this can take some time, so we have decided to move our deadline from Feb 1 st , 2017 to July 5 th , 2017. We have also added more details in the original post. If you are an Office 365 email customer and your organization is hybrid (you have an on-premise environment), please take some time to read it! Carolyn LiuImportant notice for Office 365 email customers who have configured connectors
If you are an Exchange Online or Exchange Online Protection (EOP) customer and you have configured connectors, this post contains important information that might impact your organization. To make sure that your mail flow isn’t interrupted, we strongly recommend that you read this post and take any necessary action before the deadline (July 5th, 2017). If your organization has a hybrid deployment (on-premises plus Office 365), you often need to relay emails to the Internet via Office 365—i.e. emails from your on-premises environment (mailboxes, applications, scanners, fax machines, etc.) that are sent to Internet recipients will be routed to Office 365 first, then sent out. Figure: Email relayed from your on-premises email servers to the Internet via Office 365 For this relay to work, your organization needs to follow these steps: Create one or more connectors in Office 365 to authenticate emails coming from your on-premises mail servers, using either the sending IP address or a certificate. Configure your on-premises servers to relay via Office 365. Configure your setup so that: a) The sender domain belongs to your organization (i.e. you have registered your domain with Office 365). For more information, see Add Domains in Office 365. OR b) Your on-premises email server is configured to use a certificate to send email to Office 365, and the CN (Common-Name) or SAN (Subject Alternate Name) in the certificate contains a domain name you have registered with Office 365 and you have created a certificate based connector in Office 365 with that domain. If neither step 3a nor 3b is true, Office 365 will NOT be able to know deterministically whether the email sent from your on-premises environment belongs to your organization. Therefore, it is important that organizations with hybrid deployments ensure that they fulfill either step 3a or 3b. This protects your organization, your domain, and your IP reputation. Beginning July 5, 2017 (changed from Feb. 1, 2017), Office 365 will no longer support relaying emails if a hybrid customer has not configured either step 3a or 3b (see detail above). Such emails will get rejected with the following error message: “550 5.7.64 Relay Access Denied ATTR36. For more details please refer to https://support.microsoft.com/kb/3169958.″ Additionally, if your organization needs the following scenarios to continue to work (and most hybrid organizations do), you need to ensure that you follow step 3b. Your organization needs to send NDR (Non-Delivery Report) or bounce messages to a recipient on the Internet and needs to relay them through Office 365. You need to send emails on behalf of domains that do not belong to your organization. Your on-premises users have forwarding rules configured, and messages need to be relayed through Office 365. For example: Contoso.com is your organization’s domain. A user in your organization’s on-premises server, kate@contoso.com, has enabled forwarding of all her messages to kate@tailspintoys.com. If john@fabrikam.com sends a message to kate@contoso.com, the message gets automatically forwarded to kate@tailspintoys.com. From Office 365’s point of view, the message is sent from john@fabrikam.com to kate@tailspintoys.com. Because Kate’s mail is being forwarded, neither the sender domain nor the recipient domain belongs to your organization. Figure: When step 3b is followed, a forwarded email from contoso.com will be allowed to be relayed via Office 365 For more details, see the step-by-step instructions below. Create or Edit a certificate-based connector in Office 365 For Office 365 to relay messages to internet that match with the scenarios listed above, you need to follow the below steps. 1. Sign in to Office 365 admin center, and go to Admin > Exchange. 2. Go to mail flow > connectors, and do one of the following: If there are no connectors, choose ’+’ (Add) to create a connector. If a connector already exists, select the connector, and choose Edit to modify it. 3. On the Select your mail flow scenario page, choose From: Your organization’s email server and To: Office 365. This creates a connector that indicates that your On-premises server is the sending source for your messages. 4. Enter connector name and other information, and then choose Next. 5. On the New connector or Edit connector page, choose the first option to use a TLS certificate to identify the sender source of your organization’s messages. The domain name in the option should match the CN name or SAN in the certificate you are using to send email and this domain must be a domain you have registered with Office 365 (see Add Domains in Office 365). For example: The certificate you plan to use has CN or SAN as contoso.com. In that case, you can enter contoso.com in the dialog below and register contoso.com in Office 365 (see Add Domains in Office 365) The certificate you plan to use has CN or SAN as <hostname>.contoso.com or mail.contoso.com. In that case, you could enter *.contoso.com in the dialog below, and register contoso.com in Office 365 (see Add Domains in Office 365) Note: Existing hybrid customers that used the Hybrid Configuration Wizard to configure their connectors SHOULD check their existing connector and ensure that it is using *.contoso.com instead of mail.contoso.com or <hostname>.contoso.com, since mail.contoso.com or <hostname>.contoso.com may not be a registered domains with Office 365. Register your domain with Office 365 You can follow the steps to register your domain here - Add Domains in Office 365. Go to Setup > Domains in the O365 Admin Center to see the list of domains registered: Prepare your on-premises email servers to relay messages through Office 365 If your organization uses Exchange server for its on-premises server, you need to configure your server to send messages over TLS. To do this, follow Set up your email server to relay mail to the Internet via Office 365, which is part 2.2 of “Set up connectors to route mail between Office 365 and your own email servers.” If you have already used Hybrid Configuration Wizard, then continue to use it, but ensure to use a certificate that matches the criteria outlined in step 5 of the previous section. Install a certificate in your on-premises environment. For details, follow “Step 6: Configure an SSL certificate” of Configure mail flow and client access. For more details about how to relay messages through Office 365, see the Setting up mail flow where some mailboxes are in Office 365 and some mailboxes are on your organization’s mail servers section of Mail flow best practices for Exchange Online and Office 365. Carolyn LiuSo how does this Deferred Delivery thing work?
There are actually 2 different types of delayed message delivery... I believe stemming form the quaintness of X400. The following applies to Exchange2000/Exchange2003. They have somewhat different behaviors, but both result in getting the message delivered to the intended recipients at some time after the specified time. The first type is delayed send. This is the typical functionality you see when using Outlook to send email. This functionality is controlled by the MAPI property PR_DEFERRED_SEND_TIME. When this property is set, the the message is kept in the MSExchangeIS SendQ. To end users, this means that their messages are visible in their Outbox. They can still double-click on them to open them, and will need to click "Send" for them to resubmitted for delivery. For an administrator, they will need to log into the users mailbox to see the message in that users Outbox. Unless the mailbox is deleted and purged The second type is deferred delivery (controlled by the MAPI property PR_DEFERRED_DELIVERY_TIME). The key difference is that the delay happens on the "delivery" side once transport "owns" the message. While the phrase "deferred delivery" might make you think that message is held on the destination server, it is in fact held in the queues on the source server. From the end-users perspective, the message immediately disappears from their mailbox and they cannot modify it if something occurs to them later. This is somewhat moot, as the past several versions of Outlook do not use this feature. For the email administrator, the message is queued up in the MDB temp tables along with all of the other mail. In Exchange2003, these messages are also exposed through the queues node of the Exchange System Manager. Deleting and purging the mailbox have no effect on these messages, but deleting the MDB they are queued on will make the messages disappear. - Michael SwaffordDoes your Transport think it is Squeaky Lobster Day in your CountryOrRegion?
Today is the magical day when parents tell their tucked-in children the story of the Squeaky Lobster. So here's a Squeaky Lobster-ish post to celebrate the day. In Exchange 2007, we introduced transport rules – a powerful feature that allows you to inspect different parts of a message such as sender, recipient, subject and headers and take actions like rejecting a message, deleting it, redirecting it to another recipient, adding a message header or a disclaimer. In previous versions of Exchange, you would need to write a transport event sink to accomplish similar things. With an easy-to-use interface in the EMC , transport rules make such tasks as easy as creating Inbox rules (created by users using Outlook/ OWA ). Command-line jockeys can create and manage transport rules using *-TransportRule cmdlets from the Shell. More about transport rules in Understanding Transport Rules. In Exchange 2010, we added a number of new predicates (which are used to create conditions and exceptions), including the ability to inspect attachment content and predicates to evaluate Active Directory attributes of the sender or recipients. A complete list of predicates can be found in Transport Rule Predicates. Ability to inspect Active Directory attributes of the sender or recipients dramatically increases the number of things you can check and the type of rules you can create. For example, you can check if the sender or recipients are in the same department, report to the same manager, check if the sender is the recipients’ manager (or the other way round), check the sender's title, city, state or country, amongst other things. The list of supported attributes is included in the Predicate Properties table in Transport Rule Predicates, or you can also see them in the New Transport Rule and Edit Transport Rule wizards in the EMC . Evaluate the sender's country or region You can use the predicate to evaluate the sender's country. This can be useful in many scenarios - for example, applying a disclaimer to messages based on the sender's country. Important: When using Active Directory attributes to meet business requirements, you must have appropriate processes in place to ensure the necessary attributes are populated and up-to-date. You can add the country/region property to a user or contact using ADUC , the EMC , the Shell or by using LDAP utilities. If you use ADUC or EMC, you’re greeted with a nice little drop-down list to pick a country/region from. If you use the Shell, you must use the corresponding cmdlet to populate the CountryOrRegion property – Set-User for user accounts, Set-Contact for contacts. Fig 1: You can select a recipient’s country or region from recipient’s properties in EMC You need to create a rule to check if message sender is from a specified country – let’s continue with Germany as the example, to apply a disclaimer. You can use the when the sender’s properties contain specific words predicate from the New Transport Rule wizard in EMC to check the CountryOrRegion property. The predicate allows you to pick a supported property and you can type in a string to match. For example, if you’re trying to match senders from Germany, you instinctively type in Germany. Fig 2: Checking a sender CountryOrRegion property using a transport rule But the transport rule doesn’t fire on any messages sent by recipients from Germany! You check the rule in EMC – it says Germany. It’s spelt correctly, no typos. You use the Shell to retrieve the properties: (Get-TransportRule MyRule).Conditions | fl * The value correctly displays as Germany: Words : {countryorregion:Germany} Name : SenderAttributeContains Rank : 36 LinkedDisplayText : when the sender's properties contain specific words IsValid : True You check the recipient’s country property using the Shell. Get-User bsuneja | select cou* Squeaky Lobster! The value is Germany! Why wouldn't the rule fire? The CountryOrRegion Property Although the CountryOrRegion property displays the country’s name (think of it as a display name), what’s stored in the Country-Name attribute (ldapDisplayName: c) in the recipient object in Active Directory is the 2-letter ISO 3166-1 country/region identifier for the country. For Germany, it’s DE. The full list of ISO codes can be found in the ISO 3166-1 decoding table . (Update: A better-formatted list can be found in ISO 3166-1 on Wikipedia). Note: Active Directory objects also have two more attributes to identify country or region: 1) Country-Code (ldapDispla yName: countryCode), which corresponds to the ISO 3166-1 numeric code 2) Text-Country (ldapDisplayName: co), which is the country name. However, only the Country-Name attribute is replicated to the Global Catalog. Update the rule Armed with this information, you can fix the rule in EMC. Figure 3: Use the Edit Transport Rule wizard to update values for the CountryOrRegion property Or use this command from the Shell to update the SenderADAttributeContains predicate. Set-TransportRule MyRule –SenderADAttributeContains “CountryOrRegion:DE” Happy Squeaky Lobster Day! Bharat SunejaImportant notice for Office 365 email customers who have configured connectors
Note: This post, originally published in March, got accidentally re-published on 8/23/16 when updating step 5 below. We are leaving it published as a reminder to our customers as the time for this change is now closer. If you are an Exchange Online or Exchange Online Protection (EOP) customer and you have configured connectors, this post contains important information that might impact your organization. To make sure that your mail flow isn’t interrupted, we strongly recommend that you read this post and take any necessary action before the deadline (July 5th, 2017). If your organization has a hybrid deployment (on-premises plus Office 365), you often need to relay emails to the Internet via Office 365—i.e. emails from your on-premises environment (mailboxes, applications, scanners, fax machines, etc.) that are sent to Internet recipients will be routed to Office 365 first, then sent out. Figure: Email relayed from your on-premises email servers to the Internet via Office 365 For this relay to work, your organization needs to follow these steps: Create one or more connectors in Office 365 to authenticate emails coming from your on-premises mail servers, using either the sending IP address or a certificate. Configure your on-premises servers to relay via Office 365. Configure your setup so that: a) The sender domain belongs to your organization (i.e. you have registered your domain with Office 365). For more information, see Add Domains in Office 365. OR b) Your on-premises email server is configured to use a certificate to send email to Office 365, and the CN (Common-Name) or SAN (Subject Alternate Name) in the certificate contains a domain name you have registered with Office 365 and you have created a certificate based connector in Office 365 with that domain. If neither step 3a nor 3b is true, Office 365 will NOT be able to know deterministically whether the email sent from your on-premises environment belongs to your organization. Therefore, it is important that organizations with hybrid deployments ensure that they fulfill either step 3a or 3b. This protects your organization, your domain, and your IP reputation. Beginning July 5, 2017 (changed from Feb. 1, 2017), Office 365 will no longer support relaying emails if a hybrid customer has not configured either step 3a or 3b (see detail above). Such emails will get rejected with the following error message: “550 5.7.64 Relay Access Denied ATTR36. For more details please refer to https://support.microsoft.com/kb/3169958.″ Additionally, if your organization needs the following scenarios to continue to work (and most hybrid organizations do), you need to ensure that you follow step 3b. Your organization needs to send NDR (Non-Delivery Report) or bounce messages to a recipient on the Internet and needs to relay them through Office 365. You need to send emails on behalf of domains that do not belong to your organization. Your on-premises users have forwarding rules configured, and messages need to be relayed through Office 365. For example: Contoso.com is your organization’s domain. A user in your organization’s on-premises server, kate@contoso.com, has enabled forwarding of all her messages to kate@tailspintoys.com. If john@fabrikam.com sends a message to kate@contoso.com, the message gets automatically forwarded to kate@tailspintoys.com. From Office 365’s point of view, the message is sent from john@fabrikam.com to kate@tailspintoys.com. Because Kate’s mail is being forwarded, neither the sender domain nor the recipient domain belongs to your organization. Figure: When step 3b is followed, a forwarded email from contoso.com will be allowed to be relayed via Office 365 For more details, see the step-by-step instructions below. Create or Edit a certificate-based connector in Office 365 For Office 365 to relay messages to internet that match with the scenarios listed above, you need to follow the below steps. 1. Sign in to Office 365 admin center, and go to Admin > Exchange. 2. Go to mail flow > connectors, and do one of the following: If there are no connectors, choose ’+’ (Add) to create a connector. If a connector already exists, select the connector, and choose Edit to modify it. 3. On the Select your mail flow scenario page, choose From: Your organization’s email server and To: Office 365. This creates a connector that indicates that your On-premises server is the sending source for your messages. 4. Enter connector name and other information, and then choose Next. 5. On the New connector or Edit connector page, choose the first option to use a TLS certificate to identify the sender source of your organization’s messages. The domain name in the option should match the CN name or SAN in the certificate you are using to send email and this domain must be a domain you have registered with Office 365 (see Add Domains in Office 365). For example: The certificate you plan to use has CN or SAN as contoso.com. In that case, you can enter contoso.com in the dialog below and register contoso.com in Office 365 (see Add Domains in Office 365) The certificate you plan to use has CN or SAN as <hostname>.contoso.com or mail.contoso.com. In that case, you could enter *.contoso.com in the dialog below, and register contoso.com in Office 365 (see Add Domains in Office 365) Note: Existing hybrid customers that used the Hybrid Configuration Wizard to configure their connectors SHOULD check their existing connector and ensure that it is using *.contoso.com instead of mail.contoso.com or <hostname>.contoso.com, since mail.contoso.com or <hostname>.contoso.com may not be a registered domains with Office 365. Register your domain with Office 365 You can follow the steps to register your domain here - Add Domains in Office 365. Go to Setup > Domains in the O365 Admin Center to see the list of domains registered: Prepare your on-premises email servers to relay messages through Office 365 If your organization uses Exchange server for its on-premises server, you need to configure your server to send messages over TLS. To do this, follow Set up your email server to relay mail to the Internet via Office 365, which is part 2.2 of “Set up connectors to route mail between Office 365 and your own email servers.” If you have already used Hybrid Configuration Wizard, then continue to use it, but ensure to use a certificate that matches the criteria outlined in step 5 of the previous section. Install a certificate in your on-premises environment. For details, follow “Step 6: Configure an SSL certificate” of Configure mail flow and client access. For more details about how to relay messages through Office 365, see the Setting up mail flow where some mailboxes are in Office 365 and some mailboxes are on your organization’s mail servers section of Mail flow best practices for Exchange Online and Office 365. Carolyn LiuMail Flow Troubleshooter in Exchange Troubleshooting Assistant (ExTRA) - A closer look
Have you tried the "Exchange Mail Flow Troubleshooter" in Exchange Troubleshooting Assistant v1.0 (ExTRA)? This is a new troubleshooter that you can use to troubleshoot common mail flow problems you see on Exchange servers. It is designed to identify the root cause of detected symptoms so that you can take a right course of corrective actions quickly. For example, the mail flow troubleshooter can identify common root causes such as: Messages backing up in remote delivery queues due to bad DNS configuration or unintentional third party software settings Messages backing up in the Messages awaiting directory lookup queue due to heavy distribution group expansions or permissions inheritance blocks Messages can not be received from the Internet due to metabase corruption For this blog post, I would like to introduce some of the features of this troubleshooter for Exchange 2000 Server and Exchange Server 2003. When you select "Mail Flow Troubleshooter" at the Task Selection screen, you will be presented with the selections of symptoms you would like to troubleshoot. 1. Users are receiving unexpected non-delivery reports when sending messages When you or your users receive a non-delivery report, this is the one you would like to select. The tool will further prompt you what DSN code the non-delivery report contains and provide you with guidance on what the DSN code generally means and what actions are suggested. For example, for the DSN code 5.1.6, you will see the following message in the output report: "The user directory attributes, such as homeMDB or msExchHomeServerName, may be missing or corrupted. Troubleshooting: Verify the integrity of the user directory attributes, and then run the Recipient Update Service again to make sure that the attributes that are required for transport are valid." For some DSN codes, the tool checks whether the records in DNS are consistent. In this v1.0, not many troubleshooting functions for non-delivery reports have been automated but we expect that more will be in future releases. 2. Expected messages from senders are delayed or are not received by some recipients You would like to select this when you or your users see symptoms like the following: - Your organization is not receiving any messages from the Internet - Some users can receive mails from the Internet but some users can not The possible root causes of this kind of issues (or mail flow issues in general) can vary from a transient network condition to a suboptimal SMTP configuration. Thus the mail flow troubleshooter executes a wide variety of troubleshooting steps. Area Troubleshooting Steps Connectivity - 'Ping' the designated gateway/bridgehead server to check general network health - Test connectivity over port 25 and other designated SMTP ports to the designated gateway/bridgehead server - Check SMTP service / SMTP virtual server status - Check filtering configuration (Sender ID, IMF, Recipient, Connection, Sender) Mail Acceptance - Send a test mail from the designated gateway/bridgehead to the designated address - Check for known SMTP proxies that may be blocking SMTP conversations Message Tracking - Scan message tracking logs beginning from the sending server to the destination server to see how far the test message has traveled (start the queue troubleshooter if a backup is detected) Domain Routing - Verify that local domains are correctly registered in the metabase (e.g. an error will be logged if a local domain is registered as an external domain in the metabase) Here are a few examples of the result output for this symptom. 3. Messages destined to recipients are delayed or are not received by some recipients This is the opposite direction of #2 in terms of the mail flow. You may want to select this when: - No messages are going out to the Internet - You can not send messages to a specific domain - You can not send messages to a specific external address Here are the major steps the mail flow troubleshooter executes to troubleshoot this symptom. Area Troubleshooting Steps Message Tracking - Locate the most recent message submitted by the specified sender to the specified recipient - Scan message tracking logs beginning from the sending server to see how far the message traveled (start queue troubleshooting if a backup detected) Exchange Gateway - Check SMTP service / SMTP virtual server status - Check SMTP connector configuration Domain Routing - Check address space (remote domain) settings in SMTP connector and metabase 4. Messages are backing up in one or more queues on a server We call this the "Queue" troubleshooter. It can be launched directly from the Task selection screen as well as it may be triggered by selecting #2 and #3 above. In many cases when we troubleshoot issues like "mails are not coming from the Internet" or "mails are not going out to the Internet," we find out that messages are actually backing up in a queue on an internal Exchange server. In these cases, the mail flow troubleshooter triggers the "Queue" troubleshooter automatically. For this first release, we mainly focused on developing the troubleshooting steps for the following SMTP queues. - Remote delivery - Messages awaiting directory lookup - Local delivery That said, we have general troubleshooting steps for other queues such as "Messages pending submission" and "Messages waiting to be routed" and expect adding specific troubleshooting steps for those queues in future releases. Area Troubleshooting Steps Queue Status - Detect any retry/frozen queues and also queues with a large number of messages Remote Delivery - Test whether DNS servers can be accessed from the "problem" server - Check whether DNS returns valid records for the remote hosts - Test connectivity to the remote hosts (ping, port 25) - Check remote SMTP virtual server configuration/status - Throw various SMTP commands (e.g. BDAT) - Check metabase for event sink registrations - SMTP Proxy existence - Detect antivirus software blocking SMTP ports - Link state check Messages awaiting directory lookup - Categorizer performance - DL expansion checks - Check for common destinations in messages - Check file version for known bugs - Check journaling configurations - Check whether permissions inheritances are correct - Investigate disk performance - DC/GC availability Local Delivery - Check for any dismounted databases - Check for missing SMTP system mailboxes - Event 326/327 occurrence - Common issues (PF hierarchy, Missing working directory, etc.) Here are some examples of the result output for this symptom. Thanks for your interest in the new tool. Please feel free to post comments to this blog post. Also visit microsoft.public.exchange.tools newsgroup for more discussions. - Haruya ShidaExchange Online Protection: A Premium Protection and Policy Service for Email
This summer, Microsoft introduced the new Office, including the new version of Exchange Server 2013 and Exchange Online, which provides businesses with robust communication and collaboration capabilities available on-premises or in the cloud. When you talk about messaging and collaboration, especially within the larger context of cloud services, one of the questions to quickly follow is, how do we keep our organization safe from spam and malware? Today, many Exchange Server and Exchange Online customers use Forefront Online Protection for Exchange (FOPE) for messaging protection, policy enforcement, and mail-routing control. The next release of FOPE will be called Exchange Online Protection (EOP). EOP provides the protection and control you’ve become accustomed to with FOPE, but with new features too. EOP is available as a stand-alone cloud service if you run Exchange, or another messaging solution, on-premises. If you have an Office 365 subscription, EOP is directly integrated in the Exchange Administration Center, which provides a seamless experience for administrators managing and protecting their organization’s mailboxes. Messaging Protection in the Exchange Administration Center Forefront Online Protection for Exchange (FOPE) had a user interface separate from on-premises Exchange Server and Exchange Online. The new EOP user interface is identical in appearance with the Exchange Administration Center for on-premises customers, For Exchange Online customers, EOP features have been integrated directly. EOP Features at a Glance EOP provides inbound and outbound spam and malware filtering, reporting, message trace, and mail-flow configuration features. Some of these features were included with FOPE, and in many cases have they have been enhanced. EOP features include the following: URL lists for spam filtering that block messages containing specific URLs within their message body. EOP includes additional lists beyond those available in FOPE. The ability to skip spam filtering for trusted senders, based on subscription lists The ability to filter messages written in specific languages, or sent from specific countries or regions Malware filtering that can delete and strip unsafe attachments The capacity to mark bulk email (such as advertisements) as spam through the user interface The capability to search for, view, or release quarantined email messages in the EAC Transport rules which you can use to control mail flow, based on a message’s content Message tracing capability, which allows you to search for and view details about a specific message Inbound connectors and outbound connectors you can use to enforce secure communication between you and a partner, or to make hybrid mail flow (where you host a portion of your mailboxes on-premises and a portion in the cloud) possible New reports, which you can use to monitor your organization’s mail flow, available in the Office 365 portal, by using a Microsoft Excel download application, or by using a Web service. Anti-Spam Protection Anti-spam protection is comprised of connection filtering, content filtering, and outbound spam processing. You can configure settings so that they are tailored to best meet the needs of your organization. Connection Filter Connection filtering is based on blocking or allowing inbound messages, based on the originating IP address. The connection filter checks IP Allow and IP Block lists prior to checking the content of each message. Messages from specifically allowed IP addresses bypass filtering. Messages from senders in the IP Block list are blocked, except in cases where they also appear in the IP Allow list. In the EAC, you can add an IP address or address range to an IP Allow list or IP Block list without hassles. You can also check Enable safe list to skip messages from trusted senders, derived from lists that Microsoft subscribes to. Content Filter Content filtering examines each part of the inbound email message, such as the header and message body, using a list of regular expressions. A score is then assigned to the message if a rule is matched. Several URL lists are also used to block messages that contain specific, suspicious URLs. You can configure actions for each confidence-threshold level by editing the default content filter policy. For example, you can send messages to the quarantine or to the Junk Email folder of each recipient. Content filtering includes international filtering, which means that you can choose to block messages written in specific languages or sent from specific countries or regions, and Advanced Spam Filtering Options, which inspects attributes in a message and acts upon the message if it matches a specific configured attribute. If you are concerned about phishing, some advanced options offer a combination of Sender ID and SPF-record technologies to authenticate and verify that messages are not spoofed. Outbound Spam Why do you need outbound spam filtering? Because malicious programmers and their malware are out there taking over computers inside corporate networks every day. This means that users in your organization can be sending large amounts of outbound spam without your knowledge. EOP includes outbound spam filtering to protect your organization and your email recipients, including your customers and partners, from spam. You can configure outbound spam settings in the EAC. Malware Filtering Malware consists of viruses and spyware, and is used to harm computer operations and collect sensitive information from victims. EOP uses multiple anti-malware scan engines to protect against malware threats. In addition to this, EOP includes a real-time threat response. This means that when outbreaks occur, the anti-malware team can write specific policy rules that detect the threat and protect your organization even before definitions are available from the anti-malware engines used by the service. EOP’s malware filter in the Exchange Administration Center allows you to customize your default company-wide malware filter policy, including how to take action on detected malware and who to notify in case malware is detected. You can also customize these notification messages. Transport Rules Your organizations may be required by law, regulatory requirements, or company policies to apply messaging policies that limit the interaction between recipients and senders, both inside and outside the organization. Using Exchange Transport rules, which replace Policy rules in FOPE, you can look for specific conditions on messages that pass through your organization and take action while messages are in transit. Transport rules let you apply messaging policies to email messages and prevent information leakage. Interesting new features for Transport rules include new predicates and actions. New predicates include those that can check the name extension for an attachment, or check for a message that exceeds a specified size. New actions include how to notify a sender in case a Transport rule is invoked, or the ability to require Transport Layer Security (TLS) on messages routed outside of your organization. Quarantine Messages that are identified as spam or that match and Exchange transport rule can be sent to the quarantine. If you are an administrator, you can search for quarantined messages, view details about quarantined messages, release specific messages to a recipient within your organization and also quickly report a quarantined message as a false positive. Message Trace What happened to the email I sent you? It’s a common question heard in any organization, from end users and IT folks. The message trace feature enables you as an administrator to follow email messages as they pass through your EOP service. It helps you determine whether a targeted email message was received, rejected, deferred, or delivered. This lets you efficiently answer your user’s questions and troubleshoot mail flow issues, and alleviates the need for users to contact technical support for assistance. Connectors You may have a situation that requires secure transmission of messages to a specific partner, or one where you have specific policies for mail traveling from your cloud mailboxes to your on-premises Exchange mailboxes, in a hybrid environment. With Inbound connectors and outbound connectors, you get fine-tuned control of mail flow, including the ability to apply security policies based on the IP address and domain of a sender or recipient. Reporting EOP offers a variety of reporting features both in and out of the Exchange Administration Center (EAC). Audit logging and reports are included in the EAC. Audit logging reports track specific changes made by administrators in order to help you meet regulatory, compliance, and litigation requirements. Additional reports are available with the Excel Download Application. You can use the Mail Protection reports for Office 365 reporting workbook to gather messaging statistics and details, if you are part of a Microsoft Office 365 Enterprise organization. After you download the workbook to your local computer and configure it, the workbook connects to your organization and retrieves messaging data. The data includes information about message traffic, spam, malware, and messages affected by transport rules. For Exchange Online customers, additional reports are available in the Office 365 portal. These include a report that shows the number of active and inactive mailboxes. (A mailbox is considered active if a user has accessed it at least once in the last 30 days.) Another shows the number of groups created and deleted by day, week, month, or year. There are also plans for additional reports, available via Web services, slated for the general availability (GA) release. Conclusion The new and improved EOP service brings anti-spam and anti-malware protection settings directly into the new EAC. EOP features include filters, reports, quarantine, troubleshooting tools, and connectors that enable you to protect your users and fine-tune your email messaging environment. Tony TrivisonHow to Configure S/MIME in Office 365
S/MIME in Office 365 S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and digital signingof MIME data. Configuring S/MIME in Office 365 is a slightly different procedure than configuring S/MIME on-premises. This blog is for people who want to move from on-premises to Exchange Online and want to continue to use S/MIME. This article will also apply to any Office 365 customers who want to use S/MIME for sending digitally signed and encrypted mails. Configuring S/MIME will allow users to encrypt and/or digitally sign an email. S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity, non-repudiation of origin (using digital signatures), privacy, and data security (using encryption). Further, Office 365 also provides the capability for end users to compose, encrypt, decrypt, read, and digitally sign emails between two users in an organization using Outlook, Outlook Web App (OWA) or Exchange ActiveSync (EAS) clients. Below, we will take you through the configuration steps that you will need to follow to configure S/MIME for Exchange Online Only (Scenario 1), and for Exchange Hybrid(Scenario 2). Scenario 1: Exchange Online In this scenario, all the users are hosted on cloud and there is no on-premises Exchange organization. Requirements .SST File (Serialized store): The SST file contains all the root and intermediate certificates that are used when validating the S/MIME message in Office 365. The .SST file is created from certificate store explained below. End user’s certificate for signing and encrypting the message issued from Certificate Authorities(CA) either Windows based CA or Third party CA. Configuration Remember that in Exchange Online, only the SST will be used for S/MIME certificate validation. 1. Create a .SST file for the Trusted Root CA / Intermediate CA of the certificate issued to the users: You can use either Certificate MMC or PowerShellcmdlets to export SST file. I am using Certificate console to export the .SST here: Open certmgr.msc snap-in, expand Trusted Root Certificate Authorities > Certificates > select the CA Certificates which issued the certificates to end users for S/MIME and right click > All Tasks > Export… Note: There may be some Intermediate CA’s. You can move them to Trust Root CA folder and select them (including the Trusted CA certificates) and export it all in one .SST file. 2. Select Microsoft Serialized Certificate Store(.SST) > Click Next and save the SST file: 3. Upload .SST to office 365 server: Update the SST on office 365 exchange server by executing the following commands using remote PowerShell. $sst = Get-Content <sst file copied from the box>.sst -Encoding Byte (Example: $sst = Get-Content TenantRoot.sst -Encoding Byte) Set-SmimeConfig -SMIMECertificateIssuingCA $sst 4. Publish user’s certificate to the Exchange Online GAL (Global Address List) using Outlook. If not published, users will not be able to exchange S/MIME encrypted messages. Note: To publish the certificate, the user must first have the certificate installed on their local machine. On the File menu in Outlook 2013, click Options. On the Outlook Options window, click Trust Center, click Trust Center Settings..., and then click Email Security. In the Trust Center window, click Settings… (Here, you need to choose certificate issued by the CA you are going to use for S/MIME). In the Change Security Settings window, type the Security Settings Name (you can name it anything) and choose Signing and Encryption certificate. Select the appropriate certificate assigned in previous steps, leave the Algorithm default and click OK. Once the information is selected, you will notice the Default Setting is populated with Security Settings Name. Now you can click the Publish to GAL button. To publish the certificate to the GAL, click OK. 5. To confirm the certificate is published in AAD (Azure Active Directory), connect to Exchange Online using remote PowerShelland run following command. Check to make sure that the UserSMimeCertificate attribute is populated with the certificate information. If not, return to step 4. Get-Mailbox <user> | FL or FT *user* 6. Once you confirm the end user has the certificate on their machine under certificates > personal store and also published in AAD, the users can use Outlook, OWA, or EASto send and receive S/MIME messages. Note: Make sure you check S/MIME Supported Clients section below before exchanging S/MIME messages. Scenario 2: Exchange Hybrid In Exchange Hybrid topology, some mailboxes are homed on-premises and some mailboxes are homed online, and users share the same e-mail address space. Requirements: Public Key Infrastructure (PKI). You can use Active Directory Certificate Services to issue certificates to the end users. SST File (Microsoft serialized certificate store). Tenant admins will have to configure their tenant in O365 with signing certificates issuing CA & Intermediate certs information. They will have to produce a SST file, which is a collection of certificates, and then later import it into O365 to validate S/MIME. DirSync. You will need version 6593.0012 or higher of the DirSync tool. DirSync is used to synchronize the Active Directory user object to the Azure AD, so that cloud users can also see the certificate information of recipients when performing S/MIME (encrypt) operation. You can verify the DirSync version following these steps: Open Control Panel. Click Programs. Click Programs and Features. Click Windows Azure Active Directory Sync tool. Check the version as the screenshot below: Configuration: Public Key Infrastructure (PKI) The users in your organization must have certificates issued for digitally signing and encryption purposes. You can either install Certificate Authority On-premises to issue certificates to the end users or have third party certificates issued to them. There are two attributes in a user object where certificate information stored: 1) UserCertificate and 2) UserSMimeCertificate. UserCertificateis populated automatically in on-premises deployment with a Windows root CA. This is populated at the time the user enrolls for a user certificate. This could be done manually for each user, or an administrator can set a GPO to automatically enroll all users. Certificates are stored in the userSMimeCertificate attribute when an Outlook client publishes a certificate to GAL. Outlook 2010 and above will populate both attributes with the same certificate http://support.microsoft.com/kb/2840546. But Outlook 2007 and below will not. http://support.microsoft.com/kb/822504 2.When setting a SST file, remember in Exchange online, only the SST will be used for S/MIME certificate validation. Create a SST file for the Trusted Root CA / Intermediate CA of the certificate issued to the users: You can use either Certificate MMC or PowerShellcmdlets to export the SST file. I am using the Certificate console to export the SST here: Open certmgr.msc snap-in, Expand Trusted Root Certificate Authorities > Certificates > select the CA Certificates which issued the certificates to end users for S/MIME, and right click > All Tasks > Export… Note: There may be some Intermediate CA. If there are, move them to Trust Root CA folder and select them, including the Trusted CA certificates, and export them all in one .SST file. Select SST > Click Next and save the SST file: Upload .SST to Office 365 server: Update the SST on Office 365 Exchange server by running the commands below using remote PowerShell: $sst = Get-Content <sst file copied from the box>.sst -Encoding Byte (Example: $sst = Get-Content TenantRoot.sst -Encoding Byte) Set-SmimeConfig -SMIMECertificateIssuingCA $sst 3.If end users are issued third party certificates, they can publish the certificate information to the GAL by following these steps: Note: To publish the certificate, the users must first have the certificate installed on their local machine. On the File menu in Outlook 2013, click Options. On the Outlook Options window, click Trust Center, click Trust Center Settings..., then Email Security. On Trust Center window, click Settings… (Here, you need to choose which certificate you are going to use for S/MIME). In the Change Security Settings window, type the Security Settings Name (you can name it anything), Choose Signing and Encryption certificate, select the appropriate certificate assigned in previous steps, leave the Algorithm default, and click OK. Once the information is selected, you will notice the Default Setting is populated with Security Settings Name. Now you can click the Publish to GAL button. To publish the certificate to the GAL, click OK. To confirm that the certificate is published in AAD (Azure Active Directory), connect to Exchange Online using remote PowerShell and run the following command. Check to see if the UserSMimeCertificate attribute is populated with the certificate information. If not, return to step 4. Get-Mailbox <user> | FL or FT *user* If Windows Certificate Authority is used, then the CA will publish the certificate information into the user object. In both cases, you need to use DirSync to replicate the on-premises Active Directory information to the cloud so that cloud users can exchange S/MIME messages. 4. After the above steps, your end users can use Outlook, OWA, or EASto send and receive S/MIME messages. Note: Make sure you check S/MIME Supported Clients section below before exchanging S/MIME messages. S/MIME Supported Clients All the client machines should have the PKI issued user certificate installed under (whichever is applicable) Certificates - Current User - Personal - Certificates - Trusted Root Certification Authorities - Certificates - Intermediate Certification Authorities - Certificates If the PKI issued certificate is not available, users will not be able to send digitally signed messages or decrypt the S/MIME encrypted messages. Outlook Web App: OWA for S/MIME - Supported only on Windows Vista or greater with browser IE9 and above. Not supported on other browsers or on MOWA (Mobile for Outlook Web Access). Third party certificates aren’t supported for OWA S/MIME; only Windows Certificate Authority issued certificates are supported. To use Outlook Web Access with the S/MIME control, the client system on which the user is running Internet Explorer must have Outlook Web Access with the S/MIME control installed. S/MIME functionality in Outlook Web Access cannot be used on a system that does not have Outlook Web Access with the S/MIME control installed. SMIME control in OWA requires .Net 4.5. All users accessing their mailboxes using OWA should install this on their machine. .Net 4.5 can be installed from Microsoft Downloads page. Outlook Outlook 2010 and above are supported. EAS Clients Windows phone 8.1 is a supported EAS client for S/MIME. To learn how to install a certificate on Windows Phone 8.1, see Installing digital certificates. For any other devices, you need to check with the device vendors. FAQ 1. Do both of these user object attributes (UserSMIMECertificate and UserCertificate) need to be populated with certificate information? Either, or both. 2. Do we support S/MIME for Cross Org/Cross Tenant? Cross Org/Cross Tenant S/MIME is not supported in Outlook Web App and EAS (Exchange Active Sync) With Outlook, it is a supported scenario. A tenant administrator may create contact objects with associated S/MIME public certificates, for users external to their organization that’d synchronize to Office 365 directory. Also, when we are looking for certificates for recipients, we check in all the Address Books. This includes the Global Address Book (GAL), the Contact Address Book (contacts folder), as well as any other address books (which includes LDAP address books). As long as we can find an entry in an address book for the recipient and it contains a certificate that we trust, then we can use it and send S/MIME mail. Note: Certificate in Exchange online GAL (for contact) is supported, however OWA client doesn’t support this scenario at present.. 3. When I select Encrypt mail and click on Send button in Outlook/OWA, I get error saying that the sender does not have a certificate. Why? In the example below, David is a sender. He was trying to send an S/MIME encrypted email message to a couple of recipients who have certificates published in the Active Directory, but David himself doesn’t have a certificate. When he clicks Send, he gets the below error. So, when sending an S/MIME encrypted message, we always check the sender’s certificate so that the message is encrypted such that the sender himself can see it from his Outlook ‘sent items’ folder. References Understanding S/MIME Special thanks to Frank Brown, Mike Brown, Timothy Heeney, Tariq Sharif, Vikas Malhotra and Eduardo Melo for reviewing this post! Suresh Kumar
