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 Liu
