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.

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 (ldapDisplayName: 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.

Or use this command from the Shell to update the SenderADAttributeContains predicate.

Set-TransportRule MyRule –SenderADAttributeContains “CountryOrRegion:DE”

Happy Squeaky Lobster Day!

Bharat Suneja

Accepting inbound mail for a DNS domain and relaying it to responsible mail hosts outside your Exchange organization was a simple process in Exchange 2003, albeit one that required some explanation, which was discussed in the following articles:

• KB 321721 How to share an SMTP address space in Exchange 2000 Server or in Exchange Server 2003
• KB 315511 XADM: How to Set Up Centralized SMTP Domain Sharing in Exchange 2000 Server for Independent Organizations

Exchange 2003 used Recipient Policies to define the domains for which your Exchange servers will accept email and to generate email addresses for your recipients using those domains.

Additionally, Recipient Policies also allowed you to apply Mailbox Manager settings, the Exchange 2003 equivalent of Messaging Retention Management (MRM).

Accepted Domains and Email Address Policies

In Exchange 2007, the Recipient Policy functionality was split into two components – Accepted Domains and Email Address Policies. As the names suggest, Accepted Domains are used to define the SMTP domains for which your transport servers will accept email, and Email Address Policies (EAPs) are used to generate email addresses for your recipients. EAPs use Accepted Domains – you must have an Accepted Domain to be able to create email addresses using that domain. For example, if you wanted your recipients to have email addresses from the domains contoso.com and tailspintoys.com, you first create an Accepted Domain for each of these domains and then create an email address policy to define the format of automatically generated email addresses – for example, firstname.lastname@contoso.com.

Whereas Exchange 2003 allowed you to use LDAP filters to apply Recipient Policies, Exchange 2010 and 2007 filter recipients using OPATH filtering syntax to apply EAPs. A number of pre-canned filters are included in the Email Address Policy interface in EMC or as parameters in the Shell, making it quite easy to use some of the more commonly used recipient properties such as company name, department, state and custom attributes 1-15 to apply policies. The pre-canned filters meet the needs of most Exchange deployments. For more complex filters, you can create a custom recipient filter by using the RecipientFilter parameter from the Shell. A custom recipient filter allow you to use a long list of recipient properties, called filterable properties, in a recipient filter. You can find a list of filterable properties in Filterable Properties for the -RecipientFilter Parameter in Exchange 2007 SP1 and SP2.

Accepted Domains and Sharing SMTP Address Spaces

The separation of domain name and email address policy objects makes sharing SMTP address spaces much easier. You can create the following three types of Accepted Domains in Exchange 2010 and Exchange 2007:

1. Authoritative domains: An authoritative domain means your Exchange organization is authoritative for the domain and knows about all its recipients. Generally, all recipients in an authoritative domain are Exchange recipients – mailboxes, distribution groups, mail-enabled public folders. Recipients can also be in other email systems, but Exchange must have a mail-enabled contact (MailContact) or a mail-enabled user (MailUser) object for them. Although one-off mail contacts or mail users can be created manually, they're generally created using directory synchronization in the following scenarios, for example:

   • Another business unit which has its own Active Directory forest
   • Another messaging system/directory in use within the same organization

   Once replicated, Exchange knows how to deliver mail to these recipients.

   Because Exchange is authoritative for the domain, it must generate a non-delivery report (NDR) for messages it accepts but can’t deliver for any reason, including for recipients it can’t find in Active Directory. You can use Recipient Filtering and silently drop mail for non-existent recipients.

2. External Relay domains: If your Exchange servers must accept email for a domain that it doesn’t have any recipients for, and then forward all such email to another mail host, you can create an External Relay domain. In this case, Exchange has no knowledge of recipients, and thus can’t take actions such as performing recipient filtering and dropping mail for recipients that don’t exist. Accepting inbound mail through a central messaging infrastructure is a common scenario. Because Exchange isn’t authoritative for the domain, it’s only responsible for forwarding mail to the next hop for that domain, which must generate any NDRs upon failure to deliver.

   To forward email for an external relay domain to mail hosts that are authoritative for the domain (or the next hop, which can then relay it on), you must create a Send Connector for that domain and specify the next hop as a smarthost. In topologies with an Edge Transport server, such email is relayed by the Edge Transport and the Hub Transport servers never need to handle messages.

3. Internal Relay domains: Internal relay domains fulfill an important need, one that required a fairly involved setup in Exchange 2003. They allow you to accept email for a domain where some recipients may exist in your Exchange organization, and some recipients may be on another messaging system. Exchange may know about recipients in the other messaging system using mail contacts or mail users. Or it may deliver all messages that can be delivered locally (on any Exchange server in the organization) and relay messages for unknown recipients to another mail host using a Send Connector for the same domain. Because Exchange is not authoritative for this domain, it does not generate NDRs for recipients it’s not responsible for.

   Internal Relay domains and Send Connectors
   One important consideration when using an internal relay domain is that the Send Connector you use to send mail for unknown recipients to another mail host can’t be sourced to an Edge Transport server, because the Edge Transport server has already been instructed to accept all mail for that domain and forward it to Hub Transport servers. Instead, the Send Connector must be sourced to Hub Transport servers and you must specify another mail host as a smarthost.

Figure 1: Creating an Accepted Domain in EMC

More details in Understanding Accepted Domains.

Accepted Domains and Recipient Filtering

When creating Accepted Domains, an important consideration is Recipient Filtering. If you use Exchange’s built-in anti-spam filters, you can filter recipients that don’t exist in your organization using Recipient Filtering. This allows you to drop a large chunk of spam (at the gateway if you’ve implemented an Edge Transport server with EdgeSync). Additionally, it also means your servers won’t be processing mail for non-existent recipients and generating a NDR for the sender, which may also be either non-existent address or a valid addresses spoofed by a spammer.

If you’re in a topology with an Edge Transport server and have EdgeSync configured, recipient information is synchronized from a Hub Transport server to the Edge Transport server, which can then use this information to drop email for recipients that don’t exist in your organization. If you don’t have an Edge Transport server deployed, you can install anti-spam agents on a Hub Transport server and enable Recipient Filtering.

Many third-party SMTP security solutions that are typically deployed in perimeter networks can also lookup recipients in Active Directory, although they may require LDAP connectivity to an Active Directory DC/GC, which sits on your internal network, or some other means for replicating recipient information. Comparatively, EdgeSync communication is outbound (Secure LDAP) from Hub Transport servers to the Edge Transport server and doesn’t require you to open any ports on your internal firewall for inbound traffic.

How does Recipient Filtering treat recipients from different types of accepted domains? For authoritative domains, where Exchange knows about all recipients, Recipient Filtering drops mail for recipients that don’t exist in Active Directory. For External Relay domains, Exchange doesn’t know about any recipients, so such filtering isn’t possible. Internal Relay domains are a grey area – Exchange may or may not know about the recipients.

You can configure whether Recipient Filtering is allowed for an Accepted Domain by setting its AddressBookEnabled property. The default values for each accepted domain type are in the following table:

For internal relay domains, it’s set to false by default – meaning Exchange (i.e. the Recipient Filtering agent, if enabled and configured to drop mail for recipients that don't exist in Active Directory) won’t check if the recipient exists. If you’re using a mechanism to replicate recipients from another Exchange organization or non-Exchange messaging system to Active Directory, you can set the property to true and have Recipient Filter check for valid recipients.

Set-AcceptedDomain foo.com –AddressBookEnabled $true

Bharat Suneja

Exchange Message Tracking Logs hold a wealth of information about email messages during transport. Utilities that can parse message tracking logs and analyze them for administrators have historically been important tools when troubleshooting certain mail flow problems.

With Exchange 2010, the message tracking log format has been modified to hold additional fields about messages. For those who enjoyed using "Process Tracking Log tool for Exchange Server 2007" in the past, you would be very pleased. We have come up with the new version which works with both Exchange 2007 and Exchange 2010. Same looks and great generated reports included!

When to use Process Tracking Log:

PTL may help in following situations:

• Message Looping
• Message failures, such as in Delivery Status Notifications (DSNs)
• List of top mail senders
• List of top mail recipients
• Top large message size generators
• Queues backing up
• Performance issues due to message load
• Simply monitoring server message load

To learn more about PTL tool and the reports it generates please review the original article, "Process Tracking Log tool for Exchange Server 2007". The article provides example outputs and how you can use these to further analyze your mail flow.

Where to download the new Process Tracking Log tool:

To install the latest PTL, please go here to download it.

Please note: this script is not officially supported by Microsoft. Please see the script for more details!

How to Use this tool:

The command set used to run the PTL script are still the same as the original tool.

Usage:

cscript ProcessTrackingLog.vbs <LogFilePath> <NumFiles> <hub|edge|all> [ <mm/dd/yyyy> | today | yesterday ]

Examples:

1) To parse one file:

cscript ProcessTrackingLog.vbs "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking\MSGTRK20110401-1.LOG" 1 all

2) To parse one file in a single directory:

cscript \data\scripts\ProcessTrackingLog.vbs "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking" 1 all

3) To parse all files in a single directory:

cscript \data\scripts\ProcessTrackingLog.vbs “C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking” 0 all

4) To parse all files in all subdirectories in a single directory:

cscript \data\scripts\ProcessTrackingLog.vbs "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking" 0 all

5) To parse 3 files in each subdirectory:

cscript \data\scripts\ProcessTrackingLog.vbs "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking" 3 all

6) To parse all files in each subdirectory that were logged yesterday:

cscript \data\scripts\ProcessTrackingLog.vbs "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking" 0 all yesterday

7) To parse all files in each subdirectory that were logged on 6/5/2011:

cscript \data\scripts\ProcessTrackingLog.vbs "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking" 0 all 6/5/2011

NOTE: use of hub and edge assume "HUB" or "GWY" in directory path, otherwise specify all. Also note that the message tracking log path location has changed between Exchange 2007 and 2010 since in Exchange 2010 the path has “V14” folder added.

All results are stored in “c:\temp\msgtrack\output” folder.

Some enhancements:

• PTL now works with both Exchange 2007 and 2010 message tracking log. Note that the actual path for message tracking log differs between Exchange 2007 and 2010.
• The tool will now automatically create the path folder “c:\temp\msgtrack\output” where the output results will be stored.
• The summary file, “MTSummaryResults.txt”, will have the Exchange version as well as PTL version listed.

We will maintain this tool from time to time or provide enhancements. Please contact Nasser, Nadeem, or me if you have any questions.

Nasser Salemizadeh, Mohammad Nadeem, Shawn Zaravar, Todd Luttinen

It’s not easy being a spam cop. But the folks on the Forefront Online Protection for Exchange (FOPE) team love it!

Their passion for being investigators and transport experts has translated into measurable impacts to help safeguard customers’ inbound, outbound and internal business mail from spam, viruses, phishing attacks, out-of-policy content and help customers focus on being productive. FOPE processes over a billion messages worldwide every day, including for Exchange Online customers. This team works hard to offer five financially backed SLA’s including 100% known virus, 98% antispam protection and 99.999% uptime.

This service goes largely unnoticed as long as the mail keeps flowing and the FOPE team works hard to help ensure that. One of our Senior Program Managers, Alexander Nikolayev, recounted that the team was able to proactively detect an organized attack mounted during the US Thanksgiving holiday and were able to counter the malicious behavior while many Americans were eating their turkey dinners. When customers went back to work the next day, they didn’t notice anything other than normal email in their inbox.

We wanted to share stories like these and some of the team’s passions with all of you in the next installment of our ESE Access to Exchange video series.

In the video, Terry Zink discusses taking a statistical approach to the way we approach designing our IP block lists and we wanted to further elaborate on this approach. FOPE offers an effective combination of anti-malware and antispam technologies to protect organizations from both known and unknown malicious software including heuristics scanning and block lists to maintain and achieve the 98% SLA. Some of our IP block lists are built to act proactively; they examine traffic history making judgments about whether communication is coming from a good sender or bad sender. Additionally, as patterns emerge to show which senders are responsible for a high volume of illegitimate messages, FOPE will automatically add the sending IP address(es) into the reputation block list so that all future messages from that particular IP are no longer accepted by the service’s global network.

We unfortunately had to cut out a lot of content to keep the running time manageable (including Alex’s Thanksgiving spam attack story and Terry’s detailed explanation on IP block lists and reputation) but let us know if you have questions and feedback for us and if you’d like to hear more about the Exchange team.

If you missed our previous video in the series, check out ESE Access to Exchange: Running Exchange Online.

Ann Vu

Note, the "ESE" in the post title is a wordplay on "easy". The post content does not have anything to do with the excellent Extensible Storage Engine (ESE) used in Microsoft Exchange and other products.

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 Trivison

Update 2/26/2013: In response to your feedback, we have also raised the limit for Office 365 for Education plans (A2, A3, A4) to 10,000 recipients per day.

In response to feedback from our customers, we have increased the recipient rate limit within Office 365 Enterprise (E1, E2, E3, E4, K1, and K2), Professionals and Small Businesses (P1), and Government plans (G1, G2, G3, and G4) to allow users to send email to up to 10,000 recipients per day. These new limits also apply to standalone Exchange Online plans (Kiosk, Plan 1, and Plan 2). Previously, the recipient rate limit for users of these plans had been set at a maximum of 1,500 recipients per day.

Recipient rate limits exist to discourage users from sending large volumes of unsolicited commercial email, commonly referred to as spam. These limits protect our online service from becoming a source of spam and, as a result of these protections, keep our customers’ email messages flowing. Datacenter enhancements have allowed us to increase this limit while maintaining the same level of protection.

These limits apply both to email messages sent within an organization and those delivered to external organizations. The best way to avoid exceeding the recipient rate limit is to use distribution groups when sending messages to large numbers of recipients. Distribution groups stored in the shared address book are counted as a single recipient toward the recipient rate limit. For more information, see Strategies to Support Bulk Email. Office 365 customers who need to send legitimate bulk commercial email — such as customer newsletters – should continue to use third-party providers that specialize in these services.

If you would like more information on recipient rate limits, see Bulk Email and Daily Recipient Rate Limits. We made this change because of your feedback. Thank you for sharing your thoughts with us, and please keep it up!

Steve Chew

Update 2/5/2013: We have also uploaded a sample that will work on Exchange 2010 servers, you can find it here.

What is a Transport Agent?

Transport agents allow Microsoft, developers in your organization and third-party vendors to hook into the Exchange transport pipeline with their code to process messages (e.g. an antivirus scanner for incoming email messages). Transport agents can process email messages that pass through the transport pipeline in many ways. An agent is a .Net assembly that has to be installed on the Exchange Client Access or Mailbox server. The agent is then loaded by the Exchange Transport service and invoked in the transport pipeline on the specified event. In Microsoft Exchange Server 2013, the transport pipeline is made of three different processes:

• Front End Transport service:   This service runs on all Client Access servers and acts as a stateless SMTP proxy to route messages to and from the Transport service on a Mailbox server.
• Transport service:   This service runs on all Mailbox servers and is virtually identical to the Hub Transport server role in previous versions of Exchange. Unlike previous versions of Exchange, the Transport service never communicates directly with the mailbox store. That task is now handled by the Mailbox Transport service. The Transport service routes messages between the Mailbox Transport service, the Transport service, and the Front End Transport service.
• Mailbox Transport service:   This service runs on all Mailbox servers and consists of two separate services: Mailbox Transport Submission and Mailbox Transport Delivery. Mailbox Transport Delivery receives SMTP messages from the Transport service, and connects to the mailbox database using an Exchange remote procedure call (RPC) to deliver the message. Mailbox Transport Submission connects to the mailbox database using RPC to retrieve messages, and submits the messages over SMTP to the Transport service.

Like the previous version of Exchange, Exchange 2013 transport provides extensibility that is based on the Microsoft .NET Framework version 4.0 and allows third parties to implement the following predefined classes:

• SmtpReceiveAgent
• RoutingAgent
• DeliveryAgent

Note: This Article will concentrate mainly on how to implement and build a SmtpReceiveAgent. The SmtpReceiveAgentFactory and SmtpReceiveAgent classes provide support for the extension of the Microsoft Exchange Server 2013 Edge Transport behavior. You can use these classes to implement transport agents that are designed to respond to messages coming into and going out of the organization.

The following list explains the requirements for using transport agents in Exchange 2013.

• The Transport service fully supports all the predefined classes in Exchange 2010, which means that any transport agents written for Hub Transport server role in Exchange 2010 should work in the Transport service in Exchange 2013.
• The Front End Transport service only supports the SmtpReceiveAgent class that was available in Exchange 2010, and third party agents can't operate on the OnEndOfData SMTP event.
• You can't use any third party agents in the Mailbox Transport service.

Exchange 2013 updates to Transport Agent Management

Due to the updates to the transport pipeline, the transport agent cmdlets need to distinguish between the Hub Transport service and the Front End Transport service, especially if Client Access server and Mailbox server are installed on the same physical server. All transport agent cmdlets now have the TransportService parameter. The values you can specify are Hub for the Hub Transport service and FrontEnd for the Front End Transport service. For example, to view the manageable transport agents in the Hub Transport service, run the command: Get-TransportAgent -TransportService Hub. To view the manageable transport agents in the Front End Transport service, run the command: Get-TransportAgent -TransportService FrontEnd. The TransportService parameter is available in all transport agent cmdlets:

• Disable-TransportAgent
• Enable-TransportAgent
• Get-TransportAgent
• Install-TransportAgent
• Set-TransportAgent
• Uninstall-TransportAgent

StripIncomingLinkReceiveAgent

This Transport Agent was designed and implemented to illustrate various Exchange 2013 transport agent functionality as well as stripping all the hyperlinks from the message body. This agent will illustrate the following functionality:

1. Setting up the Visual Studio Environment to code and build the agent
2. Adding Agent Event Handlers such as EndOfData and EndOfHeader to strip all the Hyperlink from the incoming message body
3. Enumerate through all the message body part and select the text body part and then stripping the link.
4. Removing any existing attachment from the message
5. Skipping Health messages sent by the Exchange
6. Process MimePart of the body
7. Error Handling
8. Implementing test unit to test various part of agent before installing on Exchange 2013.

Setting up the Environment

Visual Studio can be utilized to build and implement a transport agent. This lesson will show you how to build a transport agent to remove all HTML links from an incoming SMTP messages as well as illustrating on how to use the agent in the Exchange 2013 Front End Transport Service which was introduced in Exchange 2013.

1. In Visual Studio 2012, Create a new project using Templates->Visual C#->Windows->Class Library and name the project StripIncomingLinkAgent

2. Create a folder name Exchange under \StripIncomingLinkAgent\StripIncomingLinkAgent and copy the following DLLs from C:\Program Files\Microsoft\Exchange Server\Public

Microsoft.Exchange.Data.Common.dll
Microsoft.Exchange.Data.Transport.dll

3. In Visual Studio 2012, Go to Solution Explorer, Right click the References and select “Add Reference…”

4. Select Browse from the Reference Manager dialog and navigate to \StripIncomingLinkAgent\StripIncomingLinkAgent\Exchange

5. Select both dll and click add and OK

6. These two DLL will be used to integrate the agent to MSExchangeFrontEndTransport and MSExchangeTransport process.

7. First step is to rename the Class1.cs generated by Visual Studio to a meaningful name (e.g. StripIncomingLinkReceiveAgent)

8. Next Step is to create a ReceiveAgent class (naming the class StrinIncomingLinkReceiveAgent) which will inherit from SmtpReceiveAgent and add the proper references:

using System;using System.Collections.Generic;using System.Linq;using System.Text;using System.Threading.Tasks;using System.Diagnostics;using System.IO;using Microsoft.Exchange.Data.Transport;using Microsoft.Exchange.Data.Transport.Smtp;using Microsoft.Exchange.Data.Transport.Routing;using Microsoft.Exchange.Data.Transport.Delivery;using Microsoft.Exchange.Data.Mime;using Microsoft.Exchange.Data.Transport.Email;using StripLink;using StripLink.Utilities;using StripIncomingLinkAgent.Configuration; 

9. Before adding the business logic to our agent code and setup the agent call back, we need to setup a logging method to log events to the application event log:

publicstaticvoid WriteLog(string message, EventLogEntryType entryType,
int eventID, string proccessName)
{try
    {
        EventLog evtLog = new EventLog();
        evtLog.Log = s_EventLogName;
        evtLog.Source = proccessName;if (!EventLog.SourceExists(evtLog.Source))
        {
            EventLog.CreateEventSource(evtLog.Source, evtLog.Log);
        }
        evtLog.WriteEntry(message, entryType, eventID);
    }catch (ArgumentException)
    {

    }
    catch (InvalidOperationException)
    {
    }
}

10. Next step is to register our call back with the Transport EventHandlers and create our agent:

publicsealedclass StripLinkReceiveAgentFactory : SmtpReceiveAgentFactory
{publicoverride SmtpReceiveAgent CreateAgent(SmtpServer server)
    {
        IConfigurationProvider config;

        config = new StaticConfigProvider
        {
            ForceSinglePart = true,
            ForceTextPlain = true,
            FilterAuthenticated = true,
            FilterTNEF = true,
            HonorAntiSpamBypass = false,
            SkipInternalMessages = false,
            AlwaysFilterCAFETraffic = false
        };// To use the RegistryConfigProvider class - uncomment the line // below and comment above staticConfigProvider// config = new RegistryConfigProvider()returnnew StripIncomingLinkReceiveAgent(config);
    }
}publicclass StripIncomingLinkReceiveAgent : SmtpReceiveAgent
{privatestaticstring processName = "ExchagneStripIncomingAgent";privatestring machineName;private Process currentProcess;privatestaticstring FrontEndTransport = "ExchangeStripIncomingLinkFrontEndAgent";privatestatic RoutingAddress inboundProxy = new RoutingAddress(
"inboundproxy@inboundproxy.com");privatebool m_IsTNEF = false;privatebool m_IsSummaryTNEF = false;/// <summary>/// Configuration provider. Should be set by constructor./// </summary>private IConfigurationProvider configProvider;publicstaticvoid WriteLog(string message, EventLogEntryType entryType, int eventID,
string proccessName)
    {
        StripLinkHelper.WriteLog("ReceiveAgent: " + message, entryType, eventID,
                               proccessName);
    }public StripIncomingLinkReceiveAgent(IConfigurationProvider config)
    {
        configProvider = config; this.OnEndOfData += new
               EndOfDataEventHandler(StripIncomingLinkEndOfDataHandler);this.OnEndOfHeaders += new
 EndOfHeadersEventHandler(StripIncomingLinkEndOfHeadersHandler);
        currentProcess = Process.GetCurrentProcess();
        machineName = Environment.MachineName;if (currentProcess.ProcessName.ToLower().Contains("frontend"))
        {
            processName = FrontEndTransport;
        }
    }

11. Now we can implement the Event Handler logic for End of Header event handler. We are keeping the Header Event handler simple. The code checks for health messages generated by Exchange and skip processing of those messages and it adds a marker to the header to notify the backend agent that header has been processed by frontend agent:

privatebool IsHealthMessage(MailItem mailItem)
{string domainName = mailItem.FromAddress.DomainPart;
    RoutingAddress adminEmailAddress = new RoutingAddress("Administrator@" + domainName);return (mailItem.Recipients.Contains(inboundProxy) ||
                        mailItem.FromAddress.LocalPart.Contains("HealthMailbox") ||
                        mailItem.FromAddress.LocalPart.Contains("inboundproxy"));           
}privatevoid StripIncomingLinkEndOfHeadersHandler(ReceiveMessageEventSource source,
                        EndOfHeadersEventArgs e)
{try
    {if (IsHealthMessage(e.MailItem) &&
                       !(currentProcess.ProcessName.ToLower().Contains("frontend")))return;// Add a header indicating that this was processed // by a Front End Server...
        StripLinkHelper.MarkAsProcessedByCAFE(machineName, e.Headers);
    }catch (Exception except)
    {
        WriteLog("EndofHeader Exception = " + except.ToString() + processName,
                        EventLogEntryType.Error, 10, processName);
    }
}

12. End of Data Event handler has all the logic to parse the message body, create a single part (based on registry key value), convert the message to plain text (based on registry key value) and finally remove all the hyperlink from the message and save the body using StreamWriter:

privatevoid StripIncomingLinkEndOfDataHandler(ReceiveMessageEventSource source,
                        EndOfDataEventArgs e)
{try
    {
        EmailMessage message = e.MailItem.Message;
        Body currentBody = message.Body;if(ShouldSkipMessage(e.MailItem, e.SmtpSession))
        {// Message skipped, nothing to do.return;
        }           // The following Actions are only valid for// pure mime messages (Not TNEF)if (!m_IsTNEF)
        {// Do we want to make it single part// (only Valid is no TNEF)// The goal here is to remove all other mime parts// (body types, attachments) to minimize // the surface area where hyperlinks can be found.// There is no point in removing hyperlinks in the body// if there is an HTML attachment in the email. :)if (configProvider.ForceSinglePart)
            {// Once again, we try to reduce the exposure to hyperlinks.// We do this by trying to get the lowest fidelity// body, and making that the only mimepart on the message.// We hope for Text/Plain body but it could be HTML.
                MimePart mimepartLowFidelity =
                               StripLinkHelper.GetLowerFidelityBodyPart(currentBody);if (mimepartLowFidelity != null)
                {// We now remove any branches that do not contain// this node. Another option is to make the// message single part, however, this will// require merging headers of the source// part with the root part.// NOTE: This will break multipart/related messages // because they rely on the other parts// to store the other components (images, documents, etc).// This should not be an issue// if the target part is always text/plain.
                    StripLinkHelper.MakeSingleBranch(mimepartLowFidelity);
                }else
                {// TODO: Decide what to do in this scenario...// Probably route to Admin...// This is the case for TNEF messages as there// is no MimePart associated with the body.
                    WriteLog("Failed to get a low fidelity body.” + 
“Mime tree will not be simplified. Quarantine Message " +
                            processName, EventLogEntryType.Error, 10, processName);
                    source.Quarantine(e.MailItem.Recipients,
"Could not find MimePart for the body.");return;
                }
            }// Force Plain text...if (configProvider.ForceTextPlain)
            {
                StripLinkHelper.ForcePlainTextIfNeeded(message);
            }
        }elseif(configProvider.ForceSinglePart)
        {// We do honor the ForceSinglePart for TNEF, we// assume this means we don't want any attachments// so for TNEF we simply remove the message attachments.// A seperate option could be added, TNEFRemoveAttachments// if this needs to be handle independent of// the ForceSinglePart settings.
            message.Attachments.Clear();
        }// We now need to process the message.
        StripLinkHelper.ProcessEmailBody(message.Body);// TODO: For LegacyTNEF we thought we also needed to// filter the text/plain part that is included// for non-TNEF clients, but it appears modifying the body// also generates a new text/plain part so// the code below is not needed.//if (m_IsTNEF && !m_IsSummaryTNEF)//{// FilterTNEFTextPart(message);//}

        StripLinkHelper.MarkAsProcessedByFilteringAgent(message.RootPart.Headers,
                             machineName);

    }
    catch (Exception except)
    {
        WriteLog("EndofData Exception = " + except.ToString() + processName,
                            EventLogEntryType.Error, 10, processName);
        source.Quarantine(e.MailItem.Recipients,
"StripIncomingLinkAgent - Error occurred: " + except.Message);
    }
}

13. Process Body method uses the regular expression class to remove any hyperlink or website address from the body of the message:

publicclass TextToTextLinkProcessor : IHyperLinkProcessor
{privateint m_LinkCount = 0;privateconststring s_RegExBodyString =
@"((www\.|(http|https|ftp|news|file)+\:\/\/)
 [&#95;.a-z0-9-]+\.[a-z0-9\/&#95;:@=.+?,##%&~-]*[^.|\'|\# |!|\(|?|,| |>|<|;|\)])";privatebool m_bChanged = false;privatestring m_strReplacementText = string.Empty;publicbool WasChanged
{
    get
    {return m_bChanged;
    }

}

publicvoid ProcessEmailBody(Body bodyMessage)
{
    m_LinkCount = 0;            string savedContent = string.Empty;
    Stream memStream;
    Encoding encoding = StripLinkHelper.GetEncodingFromBody(bodyMessage.CharsetName);            if (bodyMessage.TryGetContentReadStream(out memStream))
    {using (StreamReader streamRead = new StreamReader(memStream, encoding))
        {// TODO: May also want to decide on size of message and// whether or not it should be processed if it is too large.
            savedContent = FilterText(streamRead.ReadToEnd());
        }// Now write the new body only if it was changed/filtered.if (m_bChanged)
        {using (StreamWriter streamWriter = new
 StreamWriter(bodyMessage.GetContentWriteStream(), encoding))
            {
                streamWriter.Write(savedContent);
            }
        }
    }

}

publicstring FilterText(string strText)
{
    Regex rgx = new Regex(s_RegExBodyString, RegexOptions.IgnoreCase);string strFiltered = rgx.Replace(strText, new MatchEvaluator(
                match =>
                {// If we got a match, mark it as changed.
                    m_bChanged = true;
                    m_LinkCount++;return m_strReplacementText;
                }));return strFiltered;
}

14. GetLowerFidelityBodyPart enumerates through all the available body type and return the plain text body:

/// <summary>/// Finds the lowest fidelity MimePart associated to a Body,/// normally Text/Plain./// </summary>/// <param name="body">The body part that we want/// to find the lowest fidelity MimePart for.</param>/// <returns></returns>publicstatic MimePart GetLowerFidelityBodyPart(Body body)
{// Nothing to work with if they are null...// Divided here for logging purposes..if (body == null)
    {returnnull;
    }elseif (body.MimePart == null)
    {returnnull;

    }
    MimePart bodyPart = body.MimePart; ;

    // If it is text already, then that's the lowest fidelity...if (body.BodyFormat == BodyFormat.Text)return body.MimePart;// Need to find lower fidelity body type at the same level.// If no parent, there are no children, so this would be the only// part at this level.// If it has a parent but the parent is not multipart then this will also// be the only child. so:// if (bodyPart.Parent == null || !bodyPart.Parent.IsMultipart)// The other option is to simply check that we have no siblings.if (bodyPart.PreviousSibling == null&& bodyPart.NextSibling == null)
    {return bodyPart;
    }// If we are here then we must have a parent and siblings. Get// the parent, find the lowest fidelity..
    IEnumerator<MimeNode> enumer = bodyPart.Parent.GetEnumerator();
    MimePart currentPart;while (enumer.MoveNext())
    {
        currentPart = (MimePart) enumer.Current;if (currentPart.ContentType.Equals(s_TextPlainContentType,
                                  StringComparison.OrdinalIgnoreCase))
        {return currentPart;
        }
    }return bodyPart;
}

15. The complete Visual Studio project can be foundhere. You can build the project by simply selecting build from the “Build” pull down menu using the release version.

16. Once the agent build is completed you can copy the StripIncomingLinkAgent from the \bin\release folder on the exchange server in the following folder:

C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\agents\SmtpAgents\StripIncomingLinkAgent

17. Use the following cmdlet to install and enable the agent on the Front End Transport on CAS. Note: if your CAS and Mailbox servers are on separate machine then you need to launch a window powershell to prevent the powershell proxy:

Launch a Window Powershell window and execute the following commands:

C:\Program Files\Microsoft\Exchange Server\V15\bin> Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
Install-TransportAgent -Name "FrontEndStripIncomingLinkAgent" -TransportAgentFactory "StripIncomingLinkAgent.StripLinkReceiveAgentFactory" -AssemblyPath "C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\agents\SmtpAgents\StripIncomingLinkAgent\StripIncomingLinkAgent.dll" -TransportService FrontEnd
Enable-TransportAgent -Identity "FrontEndStripIncomingLinkAgent" -TransportService FrontEnd

18. User the following cmdlet to install and enable the agent on the back end Transport on Mailbox:

Install-TransportAgent -Name "StripIncomingLinkAgent" -TransportAgentFactory "StripIncomingLinkAgent.StripLinkReceiveAgentFactory" -AssemblyPath "C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\agents\SmtpAgents\StripIncomingLinkAgent\StripIncomingLinkAgent.dll” -TransportService Hub
Enable-TransportAgent -Identity "FrontEndStripIncomingLinkAgent" -TransportService Hub

19. After installing the agent on back end, send an email from the pickup folder with a few link such as (www.msn.com, etc.)

20. The agent will remove all the links from the email body. Please remember that this is a sample only.

David Santamaria, Nasir Ali and Nasser Salemizadeh

I'm a support enginer in CSS. I was working with a customer who reported a mail loop error for a specific domain like contoso.com. This error was only observed in large emails.  Yeah that’s really mysterious until you figure out that the mail loop is due to size restriction on the Send connector.  I thought this was curious enough to share.

Understanding the configuration and root cause of the issue:

I initially thought that this might have been the outcome of the Edge server being configured to use an external DNS server (a DNS server that resolves external hosts). Usually, when the Edge Tranport server is configured to use an external DNS, it resolves the domain name to the public IP addresses (generally pointing to itself, the exernal firewall, or the service provider) instead of a Hub Transport server in the Active Diectory site, causing a mail loop.

On reproducing the issue, I found out that the Edge Transport server was not configured to use an external DNS server. The environment I set up to reproduce the issue looked like the diagra below:

Here's what happens in this scenario: When the Edge Transport server receives a 20 MB email from an Internet sender, it accepts it. The Edge Transport server has two connectors that match the address space - one for the address space contoso.com to the Active Directory site and one for the address space *. When making the routing decision based on all available connectors, the one from the Edge to Hub is not considered because of the size restriction (it has 10 MB size limit). The best match is the * connector from Edge to the Internet (Please go over the connector selection algorithm documented in Understanding Message Routing) which has a message size limit of 30 MB.

End result: The message is routed back to the Internet causing the message loop between the Internet and the Edge Server.

Based on whether the Send connector to the Internet is configured to use DNS or a Smart Host to deliver oubound mail, we will get one of the following NDRs:

If using DNS:

#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ##

If using a Smart Host:

5.4.6 smtp;554 5.4.6 Hop count exceeded - possible mail loop> #SMTP#

The Solution

This behavior is by design and can be easily rectified by modifying the message size limit on the connector. Based on your requirement, you can choose either of the following options:

• Set the MaxMessageSize parameter on the Receive Connector (which receives inbound mail from the Internet) to 10MB, so messages from the Interent are restricted to 10 MB.
• Set the MaxMessageSize on the Send connector from Edge to HUB to 30MB, which will allow you to receive 30 MB messages from external senders.

Mystery solved! Thanks to Arindam Thokder and Scott Landry, who helped me with getting this ready for the blog!

Suresh Kumar (XCON)

Can't send or receive email? The Mail Flow Guided Walkthrough (GWT) can help.

Problems with mail delivery can be a very frustrating for both the user and the administrator. Unfortunately, mail flow issues aren't uncommon and will likely occur at some point in time whether your mailboxes are hosted on-premises, in Office 365, or a combination of both.

To help you troubleshoot mailflow issues, we've just released the Mail Flow Guided Walkthrough (GWT). You can use the walkthrough for troubleshooting issues sending and receiving mail or when mail is delayed in the following scenarios:

• The sender’s mailbox is hosted on Office 365 and the recipient’s mailbox is outside your organization.
• The sender’s mailbox is outside your organization and the recipient’s mailbox is hosted in Office 365.
• The sender’s and recipient’s mailboxes are both located in Office 365.
• The sender’s mailbox is hosted in Office 365 and the recipient’s mailbox is located on an on-premise Exchange server and both users are in the same organization.
• The sender’s mailbox is hosted on an on-premise Exchange server and the recipient’s mailbox is hosted in Office 365 and both users are in the same organization.

The goal of this walkthrough is to assist you in resolving these issues in a timely manner by focusing on the scoping and steps used to isolate and resolve problems.

I’d like to thank everyone who contributed to the development of this troubleshooter with special recognition going to the following folks: Tom Kern, Nitin Shukla, Sainath Vijayaraghavan, Jim Martin, Bruce Wilson, Stephen Gilbert, Scott Landry, Charlotte Raymundo, Mary Browning, Star Li, Chen Jiang, Victor Zhang.

Joe Turick

We’re happy to announce that we’ve added some tests to Microsoft Remote Connectivity Analyzer (RCA), to help you test your mail flow configuration. These tests are intended for customers who use the Exchange Online Protection service to perform spam and malware filtering before sending email messages to your email servers. You can run these tests when setting up the service, or whenever you want to verify that your mail flow is set up correctly.

The Verify MX Record and Outbound Connector Test, shown in the image below, verifies that the MX record for your domain points to EOP, so that mail is routed to EOP for filtering before it reaches your mailboxes. This test also verifies that you have an Outbound on-premises connector configured to deliver email to your on-premises environment.

Figure 1: Verify MX Record and Outbound Connector Test

The Verify Service Delivery Test verifies delivery from the service to your on-premises environment by testing the connection between the service and your IP addresses or fully qualified domain names (FQDNs) defined in your Outbound on-premises connector.

For more information about how to run these tests, see Test Mail Flow With the Remote Connectivity Analyzer.

We welcome any feedback; please send comments to the following email address: exrcafb@microsoft.com.

Exchange Online Protection (EOP) Team

What is Directory Based Edge Blocking?

The Directory Based Edge Blocking (DBEB) feature in Exchange Online Protection (EOP) lets you reject messages for invalid recipients at the service network perimeter. DBEB lets admins add mail-enabled recipients to Azure Active Directory and block all messages sent to email addresses that aren’t present in Azure Active Directory.

If a message is sent to a valid email address present in Azure Active Directory, the message continues through the rest of the service filtering layers (anti-malware, anti-spam, transport rules). If the address is not present, the service blocks the message before filtering occurs, and a non-delivery report (NDR) is sent to the sender informing them that their message was not delivered.

How is DBEB enabled?

Admins can manage the DBEB feature through configuration of the domain type in the Exchange admin center (EAC). The EAC exposes two domain types:

• Authoritative - Email is delivered to valid recipients in your organization which may include local recipients as well as recipients whose messages are being routed to a shared environment. All email for unknown recipients is rejected. Setting this domain type is what enables DBEB.
• Internal relay - Email is delivered to recipients in your organization or relayed to an email server at another physical or logical location.

What does this mean for you?

There are three ways for you to purchase Exchange Online Protection (EOP). In most ways they are the same, but there are some differences. How new features are deployed is one of the differences.

EOP Standalone

You will know that the deployment is complete for your organization when you have the ability to change your domain type in the EAC.

The default domain type for a new domain in EOP Standalone is Internal relay. This domain type allows your email messages to route through EOP and have all the rules and filtering applied to them for all recipients for each of your domains.

In order to enable DBEB you need to change your domain type to Authoritative after configuring directory synchronization and ensuring that all of your mail enabled objects are present. This changes the behavior of the service so that it rejects all messages at the network perimeter to any recipient for your domain that is not present in Windows Azure Active Directory. For more information about how to set up directory synchronization, see "Use directory synchronization to manage recipients" in Manage Recipients in EOP.

EOP as part of the Exchange Enterprise CAL with Services and with Exchange Online

You have always had the ability to change your domain type in the EAC. This means that you may already have synchronized your users and configured your domains as Authoritative in order for recipient blocking to occur within EOP. The difference for you is more subtle.

Currently, messages for invalid recipients enter the filtering network and are being rejected during the same process which processes your Transport Rules. With the introduction of DBEB, messages will now be blocked ahead of the Transport Rules in the messaging pipeline.

You’ll know that the deployment is complete for your organization when you see an increase in your SMTP blocked message count in the received spam report. A reporting update is coming soon that will separate the DBEB specific blocks from the other SMTP blocks, so if you have the updated report before DBEB finished deployment, you’ll see the message count in the DBEB section of the received spamreport.

Information for Upgraded FOPE Customers

In FOPE Directory Based Edge Blocking (DBEB) allows you to upload a list of legitimate SMTP addresses to the service and take action based on those addresses. The only action that’s being introduced for DBEB in EOP is the equivalent of “Reject”.

We’ll migrate all enabled users that are present in the FOPE Administration Center to Office 365 as part of your transition from FOPE to EOP. This will ensure that your current list of FOPE users is present in the Windows Azure Active Directory when you’re upgraded. We strongly recommend that if you have any clean-up to do for the users currently in FOPE, you should do so prior to your upgrade. We also recommend that you configure directory synchronization with Office 365 before updating your MX record to point to EOP. The directory synchronization has built in logic to match up any existing user objects in Office 365 with their on-premises directory objects, based on properties like SMTP proxy address. For more information about how to set up directory synchronization, see "Use directory synchronization to manage recipients" in Manage Recipients in EOP.

For each domain within your organization, the User List Source and Directory-Based Edge Blocking mode will determine the domain type used for your upgrade. If your User List Source in FOPE is configured to use Admin Center or Directory Synchronization Tool and your DBEB mode is set to Reject, your domain will be added to EOP and configured as Authoritative. All other User List Source + DBEB mode combinations will be added as Internal relay, so if you want to enable DBEB you’ll need to change this to Authoritative after your transition is complete.

What about everything else?

• User List Source = Secure FTP: SFTP is not supported in EOP, however we are adding the ability to manage users and groups via PowerShell and will provide guidance for updating them using PowerShell. We understand that this is a change, but we believe it will be significantly better in the long term. You will still be able to manage your users and groups in bulk, as well as schedule and automate the import, so we are hopeful this will fill the same feature niche which SFTP was filling in FOPE. In EOP there are no Virtual Domains as the functionality has been replaced by being able to define specific Transport Rules, Spam Policy and Criteria Based Routing based on Groups. If your current User List Source is Secure FTP, you will not be migrated until the ability to use PowerShell for loading the recipients, and the associated guidance, has been provided. This should be coming soon. After your upgrade is finalized you will need to add your users to Office 365 and update your domain type to Authoritative.
• User List Source = Legacy Directory Synchronization Tool: The Legacy Directory Synchronization Tool is not supported in EOP. In order to maintain DBEB for your domain you will need to configure directory synchronization with Office 365 and update your domain type to Authoritative.
• Directory-Based Edge Blocking mode = Reject-Test: Reject-Test will be migrated as Internal Relay. Reject-Test in FOPE allows all mail for valid recipients to pass through the service, and will redirect messages for invalid recipients to a specific mailbox. This is useful in scenarios where you’re not 100% confident that your entire user list is populated in the service. This condition is meant to be temporary only. Transport Rules in EOP can be used to mimic the behavior and would have to be tested to each customer’s desired configuration.
• Directory-Based Edge Blocking mode = Pass-Through: Pass-Through will be migrated as Internal Relay. Pass-Through in FOPE allows filtering to be applied only for a sub-set of recipients who are provisioned in the service, and bypass filtering for all other recipients. This is useful in scenarios where you’re routing mail through the service and want to see what the filtering impact is for a subset of your domain recipients. This condition is meant to be temporary only. Transport Rules in EOP can be used to mimic the behavior and would have to be tested to each customer’s desired configuration.
• Directory-Based Edge Blocking mode = Passive (Virtual Domain Creation Only): Passive will be migrated as Internal relay. Passive mode in FOPE allows you to configure Virtual Domains for that domain without needing to provide a user list for the Parent Domain. In EOP there are no Virtual Domains, as the functionality has been replaced by the ability to define specific Transport Rules, Spam Policy, and Criteria Based Routing based on Groups.

Wendy Wilkes
Senior Program Manager
Office 365 Customer Experience

Message trace enables administrators to trace email messages as they pass through Exchange Online or Exchange Online Protection (EOP) service. It helps you determine whether a message was received, rejected, deferred, or delivered by the service.

You’ve told us that you need to be able to trace messages older than the current period of one week. We’re excited to announce that we’re increasing the look back period for message trace in Exchange Online to 90 days!

The existing functionality of looking up messages for the last week will persist and those results will be viewable immediately. When you search for messages older than a week, the request will be submitted as an extended message trace request. After the request has been processed, the trace results will be delivered to you in a CSV file by email. An example of an extended message trace request is shown below.

We’re already rolling out this feature. Look for more details later this month.

This feature applies to Exchange Online and Exchange Online Protection services. On-premises customers have the capability to manage and search message tracking logs in Exchange Server.

Want to know more about this topic? Join the Exchange engineering team and MVPs at MEC 2014 for a chance to get your questions answered. Register today at IAMMEC.com.

Vandana Kumbla
Senior Program Manager

With Exchange 2013, we released a new data loss prevention (DLP)capability based on deep content analysis that helps you identify, monitor, and protect sensitive information. We’re continually looking to expand our DLP capabilities, and today we’re bringing two new ones to you—Document Fingerprinting and Policy Tips in Outlook Web App (OWA). Both are being rolled out for Office 365 users right now, and they’ll be part of the Exchange Server 2013 SP1 release for our on-premises users (please stay tuned for more information on SP1).

Watch this short video that explains what DLP has to offer today and how the new capabilities can help your organization be more compliant.

Let’s look at these two new capabilities in more detail.

Document Fingerprinting

Document Fingerprinting enables you to match documents that are derived from the same template. This can be useful for organizations that frequently use standard forms or templates, for example:

• A hospital that has an insurance form that patients fill in, each with a different insurance provider.
• A tax processing office that uses several standard tax forms that it applies to a wide range of situations.
• A law firm that uses a standard template to drafts patent applications that it files on behalf of its clients.

To understand how this works, let’s take a look at a scenario.

Contoso Pharma is a pharmaceutical company with a research division. Employees in the research division collaborate with their peers across the company to create new products and services, and file patents to protect their intellectual property. The law firm used by the company for patent filing uses a standard template for patent applications.

Say you’re an administrator at Contoso Pharma. You can use Document Fingerprinting to define a customized sensitive information type called “Patents.” To do so, you use the new administrative interface in the Exchange Admin Center (EAC) to create a new document fingerprint. Select the file you want to fingerprint, and then select the standard template that employees use for that file, in this case, patent applications.

 
You create document fingerprints in the EAC by selecting the file and then the sensitive information type.

This creates a template of that kind of document, which is used to detect other documents that are derived from the template.

When you fingerprint a document, a template of that kind of document is created (1) that is then used to detect documents (2) created with it.

Continuing with our Contoso Pharma scenario, once the patent template is fingerprinted, you (as an administrator) can use the existing Exchange Transport Rules and DLP infrastructure to create a rule to detect email with sensitive information of type “Patents” and define any of the supported actions in DLP. For example, you could block emails with patent documents attached from being sent externally. If Contoso Pharma uses an outside counsel for filing patents, you can allow users to send the email with an override option from Policy Tips! (See the introduction to Policy Tips in OWA section below.)

Although the scenario above refers to patents, you can easily imagine document fingerprinting being used to detect sensitive information in many other circumstances, like a hospital fingerprinting custom forms that contain personal health information, or a tax processing agency fingerprinting the 1040 EZ or W2 forms in the U.S.A.

Document fingerprinting is just one method organizations can use to detect sensitive content. Here’s a quick guide to the different methods of detecting sensitive content and the uses of each:

• Detection of standardized entities supported by Microsoft out of the box. If you want to detect standard entities like credit cards, debit cards, and so on, check if this kind of detection is supported in the out-of-the-box list provided by Microsoft and, if it is, use it. You can customize this method of detection; learn how in this TechNet topic.
• Developing Sensitive Information rule packages. If you need to detect entities that are specific to your organization (for example, an insurance number or an employee number),you can develop custom rules based on a combination of regular expressions and keywords. For details, see this TechNet topic.
• Document Fingerprinting. If you have an established business practice in which you use standard forms or templates (for example, patent filings, health insurance forms, tax forms, and so on), you can use document fingerprinting to detect the completed forms. For details, see the Document Fingerprinting topic on TechNet.

Policy Tips in OWA

Policy tips are designed to notify users in your organization when they are sending sensitive information over email. Policy Tips are similar to MailTips, and you can use them in Outlook in several different ways to help your users avoid sending sensitive information in email. For example, you can use Policy Tips to:

• Inform your users of the presence of sensitive information and block the email from being sent.
• Educate your users through a Notify Policy Tip when sensitive content is present in their emails.
• Empower your users to make case by case decisions by allowing them to override the sensitive information policy—with the option of including a business justification for the override.

With this new release in the Office 365 service and Exchange Server 2013 SP1, all the rich capabilities of Policy Tips previously available in Outlook 2013 will now also be available across the OWA interfaces.

As an administrator, you have the flexibility to set these different ways of using policy tips based on your business requirements. For example, you could set up a policy to only send a notification if an email contains one or two social security numbers, but block the mail from being sent and require a business justification if an email has a spreadsheet attached that contains more than 50 social security numbers.

DLP Policy Tips in OWA and OWA for Devices

As of Exchange 2013 SP1, OWA and OWA for Devices will both have Policy Tips support. The experience is in line with the experience in Outlook 2013, where users see a Policy Tip based on the DLP rules set by their administrator. If you already have a DLP policy with Policy Tips turned on, they will automatically apply in OWA. That means administrators do not need to create new configurations or turn switches on for this feature to work in OWA.

When you include sensitive information in an email message, a DLP Policy Tip notifies you before you send the message.

Policy Tips in OWA also show the user what sensitive content was detected in an email; in Outlook, it also allows the user to report back to the administrator if they think the email content is not sensitive. This empowers users that are closest to the data to provide feedback on the efficacy of detecting sensitive content.

A callout displays the sensitive content that was detected in the email and allows the user to report a mistake in the detection.

Administrators can also block emails that contain a large number of sensitive content (for example, an Excel attachment with more than 50 credit card numbers). Just as in Outlook 2013, the attachment with the sensitive content is highlighted so the user can easily identify it. Depending on the organization’s policy, users can be empowered to override the policy—with the option of requiring them to include a business justification—and send the email.

Policy Tips can be set up to block users from sending a large amount of sensitive content; attachments with sensitive content are highlighted for the user.

These experiences are also replicated on all mobile devices, from Windows Phone to iOS and Android devices.

Policy Tips can be set up on the Mobile devices to educate users

Different kinds of Policy Tips can be triggered based on conditions, like the amount of sensitive data in an email. No new configuration is required to do this, if DLP in Outlook has already been enabled.

Shared configuration

Policy Tips in Outlook 2013 are turned on when an administrator creates a rule with a action to notify the end user with a policy tip, or configures a DLP policy with such a rule. In Exchange 2013 these rules are applied on both the server and the client (that is, Outlook 2013). These same rules now get applied in exactly the same manner in OWA as well. This means that Exchange, Outlook, and OWA all share these configurations:

• Exchange Transport Rules. When you configure a transport rule to look for sensitive content in an email, and take Policy Tip-based actions on them, they are uniformly applied in Outlook and OWA. This includes the predicates likes detecting sender group membership, and other properties of recipients as well. Specifically, the NotifySender action in Exchange Transport Rules triggers Policy Tips for both Outlook and OWA.

Different kinds of Policy Tips options can be triggered based on conditions, such as the one above where we notify the user about sensitive information but allow them to send the message.

• Definitions of sensitive content. When you configure a transport rule to look for any of the out-of-the-box sensitive content or any custom sensitive types, they are evaluated in exactly the same manner in all three places, Exchange, Outlook, and OWA. Specifically, the MessageContainsDataClassifications predicate in Exchange Transport Rules defines the sensitive content for both Outlook and OWA.

You can defining sensitive content for Outlook and OWA when you configure a transport rule.

• Policy Tip configurations. When you edit the Policy Tip configurations to customize the text displayed in a Policy Tip, or the Compliance URL, they are updated in Outlook 2013, OWA, and OWA for Devices.

Custom Policy Tip configurations, like compliance URLs or customized notification texts, are applied uniformly in Outlook, OWA, and OWA for Devices.

DLP planning and implementation are crucial for most organizations, because they impact the organization as a whole and all the users who work with sensitive data. Protecting sensitive information without decreasing users’ productivity is a key principle of DLP in Office 365, and Policy Tips and Document Fingerprinting can help you do just that. We hope adding these capabilities to our DLP arsenal will help make DLP management easier for your users. Stay tuned for more news about our work in compliance.

Shobhit Sahay

With the huge scale environment I currently work in my team has had some difficulty when it comes to validating customer transport changes, specifically when adding new send connectors or new smart hosts. The same goes for troubleshooting mail flow….you know…whip out good ole’ Telnet, check SMTP status manually and then go on from there. What happens when security bans Telnet? What happens when you have 40 transport servers that you need to validate against 20 - 30 smart hosts over multiple connectors? Or you have a gazillion address spaces over a gazillion send connectors….you need some way of automating the checks to help you with troubleshooting if you need to, or validate a transport change when you make changes to send connectors.

Well, let me introduce a very simple, yet efficient tool I branded PelNet…..yes, that’s my take on PowerShell Telnetting :-)

So, let’s see what this baby can do.

Before I get into the usages, let’s talk about the parameters the script accepts:

• AddressSpace: Which AddressSpace should the script look for in the Send Connectors?
• sendConnector: Specify if you want the scope to be a single Send Connector.
• SourceTransportServers: Accepts comma separated list of transport servers to test from.
• smartHost: The smarthost you want to test against. Accepts comma separated list value.
• mailSubmissionTest: Use this switch if you want the script to submit the mail to the mailbox. If you omit the parameter the script will skip the DATA portion of the SMTP verb.
• From: From address (test@fromdomain.com)
• Rcpt: Recipient Address (target@targetdomain.com)
• LogFolderPath: Log file and report location, default will be current path if not specified.
• Port: Default is 25, but you can specify a custom port if you need to.

Requirements

1. You need to run this from a machine that has the Exchange management tools installed. Certain parameter combinations don’t require EMS; however, the tool will automatically load the Exchange Server PowerShell snap-in, if it’s required.
2. Remote PowerShell needs to be configured so that the script is able to remote execute on the transport servers. See here.

The logic is simple: Depending on what parameters you specify, the script will validate accordingly and give you a nice CSV output that you can use to check the SMTP status codes for each server.

Script Execution Examples

Show the full help with examples

Get-help .\pelnet.ps1 –full

Let’s say you want to test your 50 transport servers against a new smarthost that needs to be added to a send connector soon.

.\PelNet.ps1 -From test@domain.com -Rcpt user@contoso.com –smarthost smarthost.domain.com

Test all source transport servers in all send connectors with a specific address space against a specific smarthost.

.\PelNet.ps1 –addressSpace contoso.com -From test@domain.com -Rcpt user@contoso.com –smarthost smarthost.domain.com

Test all send connectors with a specific address space against a multiple smarthosts on a custom port.

.\PelNet.ps1 –addressSpace contoso.com -From test@domain.com -Rcpt user@contoso.com –smarthost smarthost.domain.com –port 25070

Test every send connector with a specific address space against all the smarthosts in those send connectors.

.\PelNet.ps1 –addressSpace contoso.com -From test@domain.com -Rcpt user@contoso.com

Test all source transport servers against all smarthosts in a sendconnector.

.\PelNet.ps1 –From test@domain.com -Rcpt user@contoso.com –sendConnector Outbound_Contoso

Test a specific address space from all source transport servers to all smarthosts in all send connectors (bear in mind execution time here).

.\PelNet.ps1 –From test@domain.com -Rcpt user@contoso.com –addressSpace contoso.com

Test a specific address space from selected source transport servers to a smarthost and queue the mail for delivery.

.\PelNet.ps1 –From test@domain.com -Rcpt user@contoso.com –addressSpace contoso.com –sourceTransportServers EX15-01,EX15-02,EX15-03 -mailSubmissionTest

Script Output

Now that we covered the usage examples, let’s chat about the output.

The console output will look similar to the below screenshot. As you can see, this will show you on which transport server the tool is currently invoking the code.

The files that the tool will output is a log file and most importantly a comma separated value (.csv) file that contains the data you can use to get a holistic view of the situation you tested.

The csv file contains the following columns:

SmartHost,SendConnector,SMTPVerb,Status,TransportServer

Using the values in these columns you can determine if the server is accepting traffic or not.  Please note that the SendConnector column depends on the parameters you used.

End-To-End Example

Let’s take a look at an example. Let’s say I want to test connectivity to all smarthosts for the contoso.com address space in my organization (with a mail submission test).

.\PelNet.ps1 –From Michael.Hall@uclabz.com -Rcpt user@targetdomain.com –addressSpace Contoso.com -mailsubmissiontest

Within the BLUEbox you’ll notice the status responses and return string back from the server.

Within the REDbox, if a remote smarthost is not accepting traffic on the port you’re trying to connect to or not reachable, you‘ll get a status and ReturnString value of CONN_ERROR.

Finally in the GREEN box, the mailSubmissionTest switch was used so the tool tried to submit the test message for delivery. No response would be sent from the smarthost during the subject and content portion, thus the columns showing NULL.

It’s easy to filter on any of these columns and determine if you have a connectivity issue. You can also create a pivot table to get an overview of the results.

Summary

As you can see, this tool can be very powerful when you need to quickly test mail flow or validate a bunch of servers against a smart host or multiple smart hosts.

I hope this tool will help you, as always I’m open to any feedback or improvements.

Happy PelNetting….

Michael Hall
Service Engineer
Office 365

I wanted to write a series of blog posts talking about email spam in Office 365. While majority of spam mail is blocked by the Office 365 mail security gateways, there are no perfect systems that will block 100% of spam all the time, some can still get through. In case that we do experience spam mail, we can use several tools and configuration options that are available for us in Office 365 to deal with it and improve effectiveness.

In this series, we will quickly review different types of spam mail. Then we will present different tools that we can use for fighting spam mail in an Office 365 environment and try to “match” the “spam tool” for the task based on the type of the spam.

Also please note that while we are approaching this from Office 365 viewpoint, many of the procedures listed here apply to both on-premises and hybrid deployments.

Introduction

One of the advantages of using Office 365 is that transparently, behind the scenes, we implement EOP – Exchange Online Protection (the former mail security infrastructure was implemented by FOPE services).

The Exchange Online Protection infrastructure serves as mail gateways, which are responsible for the “Hygiene” of incoming and outgoing mail flow. The purpose of this mail gateway’s is to filter any malware, virus or spam that might be included in the mail flow that comes from external sources to Office 365 recipients (incoming mail flow) and also mail that is sent from Office 365 recipients to external sources. A bit over-simplified but think of it like this:

What should I do when EOP is not working as desired?

EOP aims to provide the best possible protection, but from time to time Office 365 subscribers can experience spam mail that gets into their mailbox.

Before going further into this, let’s not forget that there is no “perfect solution” that will block 100% of spam mail because “spam solutions\gateways”, will always need to face issues of:

• False Positive - a scenario in which the defending systems recognize legitimate mail is bad\spam mail and blocks the mail. 
• False Negative - a scenario in which the defending system doesn’t recognize bad\spam mail and the mail reaches recipients mailbox.

Certainly any hygiene solution, even a cloud-based one, will have times when a few messages originating from a creative spammer sneak through before it is recognized as a threat. The advantage that a cloud-based solution offers is that it is set up to recognize those threats quickly, partially due to the quantity of email that it processes.

Additionally, different users will always have slightly different expectations. It is therefore challenging to have a default configuration setting that is perfect for different business customers, each with unique requirements. One person’s spam email can be another person’s legitimate business email. EOP defaults tend to be slightly less strict rather than risk a false positive. If these defaults are not adequate for your organization, EOP offers great flexibility in allowing customization of anti-spam settings.

This series of blog posts will help you understand what to do in either situation.

Spam mail - Troubleshooting process and classification

To create a clear path of the troubleshooting process, we will need to implement the workflow similar to the one in the following diagram:

Step 1 - Get information about the character of the spam mail.

The most basic step is to get essential information about the spam message. Determine if the mail message is truly a spam message and if so, try to recognize the type of spam. Based on this information, choose the right “tools” for mitigating it (we will cover more of those in future posts).

Questions to answer

Here is a list of questions that could help gather required information:

• Q: Is the mail considered as spam mail or just standard advertisement mail from a well-known\familiar company?
• Q: Is the spam mail sent from a specific sender email address?
• Q: Is the spam mail sent from a specific domain?
• Q: Does the spam mail include specific keywords in the mail subject\body?
• Q: Does the spam mail include specific URLs in the mail body that redirect the recipient to another location?
• Q: Does the spam mail include characters of non-English language?
• Q: Is the spam mail from a specific geographical location?
• Q: Is the spam mail directed to a specific user or distribution list in the organization?

General characteristics:

• Q: Is the spam mail sent on a specific schedule (specific hour or date)?
• Q: What is the percentage of organization users who get the spam mail?
• Q: What is the “amount” of the spam mail (single mail item, tens or hundreds of spam mails)?
• Q: How long has the spam mail been received (days/hours)?
• Q: When was the last spam mail received?

Step 2 – Report\Block spam mail

When we deal with spam mail, we need to try to block the spam mail by using the available option from the “Server side” (Exchange online and EOP) and the “Client side” (Outlook). The process of blocking the spam mail could be implemented as a combined operation of using tools for filtering spam mail and other tools for reporting (sending a sample of the spam mail) to the Microsoft team that manages the EOP infrastructure.

Dealing with spam mail - Client side

1. Microsoft Junk E-mail Reporting Add-in

The Microsoft Junk E-mail Reporting Add-in, is a very useful Outlook add-in that enables each of the users to report the offending message to Microsoft.

By selecting the mail item and then choosing the option of “Report Junk," the mail item will automatically be sent to the Microsoft mail security team for further analysis and investigation to help to improve the effectiveness of our junk e-mail filtering technologies.

Using the Microsoft Junk E-mail Reporting Add-in

• Download and Install the Microsoft Junk E-mail Reporting Add-in.
• Report email as spam

In Outlook 2010\2013, the Microsoft Junk E-mail Reporting Add-in is implemented by additional menu option named: Report junkthat is added to the “Junk” section to be able to report an email as spam. To “mark” mail item as Junk use the following procedure: 

• Choose the mail items you would like to report
• On the Home Tab choose the small black arrow of the Junk option.
• Choose the option Report Junk

A warning message appears and informs the user that the mail item will be reported as spam. Choose the “Yes” option.

When we choose the “yes” option, the following events will occur:

• The mail items that were reported as spam, will be sent to the Junk Email folder.
• A copy of mail items will be sent to abuse@messaging.microsoft.com as attachments, as can be seen in the sent items folder
• An acknowledgement email will be sent back to the recipient.

In Outlook 2007, the option to “report junk” will be added on the top menu option.

2. Outlook Junk option - block sender

Another option that is available for us from “client side” is the Outlook junk component and the option of “block sender” (Add a sender to the Blocked Senders list).

This option is most suitable in a scenario that the spam mail is delivered from a specific recipient email address. In reality, many times the “spammers” mange to send the spam mail by using a different source recipient email address, so the option to “block sender” will not help us in such scenarios.

Add a sender to the Blocked Senders list

In case that you want to block the sender who sends spam mail, we can use the junk menu for blocking this recipient.

• Choose the required mail items,
• In the Home Tab chooses the small black arrow of the Junk option.
• Choose the option Block sender

Additional reading:

• How to obtain the latest Outlook Junk E-mail Filter update
• Overview of the Junk Email Filter

3. Unsubscribe from a mailing list

In case that the user reports “spam mail” and when checking the mail item, we see that the sender is not considered as “spammer” (mail is just a standard advertising email that is sent to a distribution list that the user is on), most of the time the mail will include an option that enables the user to unsubscribe from the mailing list.  So, before we start to use the “heavy artillery," please check if the option of “unsubscribe” exists and unsubscribe from the mailing list.

4. Educate users: How to avoid spam

Educating users to avoid spam belongs to a “proactive” section in which we are trying to avoid a scenario that could lead to spam mail. 

By providing our users instructions and guidance about behavior they should avoid, we can prevent or significantly reduce in advance the occurrence of “spam events."

You can read more information about this subject by using the following link:

10 tips on how to help reduce spam

That is all for today – part 2 (starting to talk about server side solutions) to follow soon!

Eyal Doron
Tech Lead | Office 365 | Israel

In the last related blog postwe gave some introduction about Exchange Online Protection (EOP), what needs to be done when EOP is not working as desired and spam email troubleshooting process and classification. In this blog we will be moving further and discussing some more advanced option to stop spam emails.

1. IP Block list

The “IP block list” option enables us to block email messages that came from a specific mail server (specific IP).

EOP - using the the IP Block list

• Login to Office 365 portal, Exchange admin center
• On the left-side menu bar, choose the Protection menu
• On the top menu options, choose the connection filter menu
• Choose the Default connection filter policy
• In the window that appears, choose the option: connection filtering menu.
• In the section: IP block list, Choose the plus icon to add the IP address of the Mail server that sent the spam

Additional reading

• Configure the Connection Filter Policy

2. International spam

The “International spam” is an interesting option that enables us to block or identify mail as “spam” based on the classification of Geographical location or Language.

Note: We need to be cautious when using this option because we can very easily get into the scenario in which legitimate mail is identified as “bad\spam” mail and be blocked.

Using the International spam option

• Login to Office 365 portal, Exchange admin center.
• On the left side menus, choose the protection menu
• On the top menu options, choose the content filter menu
• Choose the Default connection filter policy
• In the window that appears choose the option: international spam menu.

We can use one (or both) of the following options:

Blocking mail written in the specific language

• Choose Filter email messages written in the following languages
• Click on the Plus icon and choose the specific languages that you want to block

Blocking mail by Geographical location

• Choose Filter email messages sent from the following countries or regions
• Click on the Plus icon and choose the specific regions that you want to block

3. Content filter advanced options

Before we begin with instruction of how to use EOP advanced option for spam mail, let’s explore additional classifications of spam mail types and the tools we can use. Using a high level classification, we can define 3 “families” of spam mail types:

• Advertisement mail - negative effect of such mail could be considered as “annoying." No real damage is caused to users besides the fact that the user is troubled by the content of the mail (suggestions to buy different medications, enlarge specific body parts and so on). This type of spam mail is automatically blocked (most of the time) by the Office 365 mail gateways. In case that some Advertisement spam mail manages to “sneak in" we can use a solution such as “rules” for blocking this type of spam mail. 
• Mail with malicious content - this type of spam mail is closer to the definition of “virus” because, the target of the spammer is to cause the destination recipient to click or accept some suggestion that could lead the user to many kinds of attacks such as fraud, phishing and so on.
• “Other spam mail” - in this group, we have other spam mail types that don’t belong to the former families. As an example, we can mention spam mail described as NDR backscatter.

Content Filter - Advanced options

The “Advanced options” section under the Content Filter section enables us to “harden” the default spam policy that is implemented by the Office 365 mail security gateways. To avoid incorrectly marking legitimate messages as spam, we can use the “Test mode” (we can describe this as a “Learning mode”). This mode enables us to use the “additional security filter” and decide what will happen when a specific mail item is recognized as spam by the security filter without actuallyperforming any action. We can choose to block\delete the mail item or just report the mail item (Test mode).

Using Content Filter - Advanced options

• Login to Office 365 portal, Exchange admin center.
• On the left side menus, choose the protection menu
• On the top menu options, choose the content filter menu
• Choose the Default connection filter policy
• In the window that appears choose the option: advanced options menu.

As you can see there are many possible options that we can select. The options are divided into 2 categories: Increase spam Score and, Mark as spam.

To be able to demonstrate options available in the Content Filter - Advanced options let describe two scenarios:

• Scenario 1: Blocking spam mail with malicious content
• Scenario 2: Blocking spam mail classified as NDR backscatter

Scenario 1: Blocking spam mail with malicious content

Over the last month, users were complaining about spam mail that contains malicious content. When users open the mail item, they are automatically redirected to a web site, and once there are invited to download an executable file. To be able to block this spam mail item, we would activate three additional filters: mark as spam if the mail item is or contains:

Empty messages

JavaScript or VBScript in HTML

Frame or IFrame tags in HTML

By default, each of the security filter status is: Off. When we click on the “option arrow," we can see that we can choose the options: “Off," “On” or “Test." In case that we choose the option “On," each mail that contains content that is not allowed by one of the security filters that was selected (such as JavaScript or VBScript in HTML) will be marked as spam.

In case that we just want to test the “new security filter” we can choose the option “Test." In the following screenshot, we can see that we can choose one of the following three options:

• None
• Add the default test X-header text
• Send a BCC message to this address  (Note: This address should have a separate mailbox that is just for testing the security filters.)

Scenario 2: Blocking spam mail classified as NDR backscatter

NDR backscatter is a special kind of spam because the “mechanism” that’s used by the spammer is different from the “Standard spam mail." NDR backscatter is when spammer forges the user’s email address and sends email on their behalf to other recipients. If the “destination mail system” recognizes the mail as a spam or if the mail is sent to non-existing users, the “destination mail system” creates an NDR message that is sent to the organization recipient (the user whose email address was used by the spammer).

Generally speaking, Office 365 security gateway servers are configured to block this kind of spam mails, but in case that the spam mail manages to “sneak” through, we can add the following filter using the Content Filter - Advanced options.

Using Content Filter - Advanced options - NDR backscatter

• Login to Office 365 portal, Exchange admin center.
• On the left side menus, choose the protection menu
• On the top menu options, choose the content filter menu
• Choose the Default connection filter policy
• In the window that appears choose the option: advanced option menu.
• Choose the option: NDR backscatter, and turn on the security filter

That is all for this time. Until we meet again,

Eyal Doron
Tech Lead | Office 365 | Israel

When customers receive an email with a suspected virus, they often ask “What do I do now?”

This blog post helps answer that question and guides you through our recommended process. This is intended for customers using Office 365 or Exchange Online Protection with on-premises Exchange servers.

First, it is important to understand the difference between an infected and uninfected email. Any email that has an attachment containing a script or malicious executable is considered ‘a virus’ for our purposes. This does not include subscription-based messages with links to malicious sites. Those messages would be considered spam and not viruses, and a different approach is used for spam messages (see this and this).

To deal with an email virus, here are some quick actions that you can perform:

1. Start at the filtering layer. We recommend using EOP, as it is the default option for Office 365 users. However, if you are using a third-party filtering mechanism, you will need to contact your vendor to investigate further. If the email virus has gone through Exchange Online Protection (EOP), or if header information is missing, then proceed to the next step.

2. Create a Transport Rule to block the message. Note that Office 365 Small Business and Small Business Premium customers will not have this feature access as mentioned here. See here also for information about transport and inbox rules limits. If you are an EOP customer, you can perform these steps as mentioned in Microsoft Knowledge Base article 2959596:

• Navigate to Mail Flow in the Exchange Admin Center.
• Click + to create a new rule.
• Click More Options.

Under Apply this rule if, choose any attachment has executable content. At this point you can also choose an action under Do the following. We recommended choosing Block the message…

Make sure no other Transport rules exist that would override this rule. See Manage Transport Rules for more information.

3. Submit the email virus sample immediately to Microsoft Malware Protection Center (MMPC) for further analysis. In order to receive analysis updates, please sign into the MMPC Web site, or enter a valid email address. We recommend you to use your Microsoft account email address.

4. Once you have logged in, select O365 and Exchange Online Protection. Follow the instructions outlined on the MMPC to understand if you need to compress the email virus sample before uploading it to the site. Once you have completed the procedure, make note of the final MMPC ID that will be sent to you from the MMPC Submission Support Team.

If you are dealing with an email virus that has a sender of administrator@domain.com or fax@domain.com with domain.com being same as your Office 365 domain, we also recommend blocking the sending server’s IP address and enabling the SPF hard fail in addition to the steps mentioned above. Also, see Best Practices for Configuring EOP.

If you continue receiving infected messages or attachments, then you should copy the message headers from the email virus, and contact Microsoft Customer Service and Support for further assistance. Be sure to have your MMPC ID handy, as well.

Irol Pinto
Technical Advisor, Microsoft Corporation

Update: On August 25, 2014, the pelnet.ps1 script was updated to fix a minor bug.

EHLO Exchange community,

It seems that PelNet has been well received and I’ve been receiving requests to add much wanted functionality to PelNet. So this article is a quick update on some of the cool new features that administrators can use to help troubleshoot and validate mail flow.

The new features added in this release:

1. Ability to test against multiple recipients – this is useful if you want to test to multiple external domains without having to run the tool again.
2. Optimized remote execution against transport servers for better performance across a large amount of servers.
3. The ability to validate if TLS negotiation is working. This is one of the most useful feature additions.

The above features gave birth to two new parameters validateTLS and CertThumbPrintOverride.

Let’s recap the parameters with the new ones introduced.

• AddressSpace: Which AddressSpace should the script look for in the Send Connectors?
• sendConnector: Specify if you want the scope to be a single Send Connector.
• SourceTransportServers: Accepts comma separated list of transport servers to test from.
• smartHost: The smarthost you want to test against. Accepts comma separated list value. (when validating TLS be sure to use FQDN of remote host – certificate validation will fail if IP is used)
• mailSubmissionTest: Use this switch if you want the script to submit the mail to the mailbox. If you omit the parameter the script will skip the DATA portion of the SMTP verb.
• From: From address (postmaster@contoso.com)
• Rcpt: Recipient Addresses –accepts comma separated list of addresses (testmailbox@fabrikam.com,testmailbox@wingtiptoys.com)
• LogFolderPath: Log file and report location, default will be current path if not specified.
• Port: Default is 25, but you can specify a custom port if you need to.
• validateTLS: This switch will enable TLS validation – this changes the SMTP verb array being used to include the STARTTLS verb (and some other more complicated stuff).
• CertThumbPrintOverride: This allows the operator to override the logic used to determine the SMTP certificate assigned to the transport servers.

  This can also be used to test TLS to a specific host before assigning the certificate to the SMTP service in Exchange, i.e. pre-validations prior to production change. The certificate needs to be in the local machine certificate store.

  It’s important to note that the code logic uses best effort to determine the SMTP certificate assigned. Using the CertThumbPrintOverride parameter allows you to override this easily.

Script Execution Examples

Show the full help with examples

Get-help .\pelnet.ps1 -full

To test mail flow and validate TLS to a smarthost against all the transport servers on port 25 to multiple recipients. (Will not submit the message for delivery)

.\PelNet.ps1 -From postmaster@adatum.com -Rcpt user1@contoso.com,user2@fabrikam.com,user3@wingtiptoys.com -smarthost webmail.contoso.com -validateTLS

To test mail flow and validate TLS to a smarthost against all the transport servers on port 25 to multiple recipients. (Submits the message for delivery and override the certificate to use)

.\PelNet.ps1 -From postmaster@adatum.com -Rcpt user1@contoso.com,user2@fabrikam.com,user3@wingtiptoys.com -smarthost webmail.contoso.com –validateTLS –mailsubmissiontest –certThumbprintOverride 1A13124HJG1234K12JHG312J123D

To test mail flow and validate TLS to EOP from your hybrid servers on port 25 to multiple recipients (also submit the mail to EOP).

.\PelNet.ps1 -From postmaster@adatum.com -Rcpt user1@contoso.com,user2@fabrikam.com,user3@wingtiptoys.com -smarthost adatum-mail-onmicrosoft-com.mail.protection.outlook.com –validateTLS –sourceTransportServers E15HYBRID01,E15HYBRID02 -mailsubmissiontest

The TLS validation logic will authenticate against the remote server with the certificate assigned to SMTP or the certificate that matches the thumbprint used in the override parameter. If the remote host is configured with Opportunistic TLS and the handshake fails the session will fall back to unencrypted SMTP.

The console output won’t show the verb’s being sent as the code is invoking on multiple servers concurrently, but the final output table and output file will be exactly as previously described in PelNet 1.0.

From the below output:

STARTTLS verb being sent with server responding with 2.0.0 SMTP Server Ready and subsequent SSL Stream is established by authenticating against target host using certificate that matches thumbprint provided (or dynamically found using best effort).

Verbs being sent over SSL stream and successful recipient lookup.

The following is an example of a certificate validation issue on one server:

Some of the most common certificate validation errors are:

• Certificate revocation list not found.
• The remote hostname does not match the name on the certificate.
• Certificate is expired.
• The root certificate is not installed on the sending server, i.e. the server does not trust the remote certificate it received.

The above validation error was quickly fixed by installing the root certificate from the Contoso environment on the EX14-02 server.

Until next time,

Michael Hall
Service Engineer
Office 365

Bulk mail is often mistaken for spam and is starting to become a larger problem for organizations. EOP is not very aggressive out of the box when it comes to bulk mail because this type of mail falls into a grey area. Some organizations will want to receive this type of mail, whereas others will not.

Over the last few months we have greatly increased EOPs ability to detect bulk mail which you can take advantage of starting today. This new system is based on a scale which gives customers the ability to set the aggressiveness of bulk mail detection to meet their specific needs.

X-Microsoft-Antispam is a new header that is stamped on all messages traversing Exchange Online and only started appearing in messages few months ago. This new header currently contains two published values to help better detect bulk and phishing emails.

• BCL – Bulk Complaint Level
• PCL – Phishing Confidence Level

The beauty of this header is that it is stamped on incoming messages BEFORE the EOP transport rules are evaluated. This means EOP transport rules can be written to trigger based on what’s in this header.

One of the goals behind the new X-Microsoft-Antispam header is to allow customers to decide how sensitive they want EOP to be when it comes to bulk mail detection. Currently in the EOP Content Filter there is a bulk mail detection switch that can only be set to either On or Off.

The problem with this switch only being on or off is that bulk mail is a very grey area. What one user considers as bulk another will not. This is why EOP (with no additional configuration added) typically does not block this type of mail. This is also why we are moving beyond the On or Off switch to a multi-value type classification system where customers will be able to set the level that they are comfortable with.

With this new header, you can decide on a scale how sensitive you want the service to be with bulk mail detection. Eventually this will be rolled in to the Advanced Spam Filter options and replace the current bulk On or Off switch, but for now you can write EOP Transport Rules to start taking advantage of this today! You can choose the bulk mail detection level that makes sense for your organization.

At MEC this year there was a great presentation with the title “So how does Microsoft handle my spam?” In this presentation, bulk mail detection is discussed between 22:30 to 28:50 and the speakers provide great insight into this topic. The entire session is great, but I would recommend at least listening to the six minutes where they discuss bulk mail.

What can I do today?

If you are receiving unwanted bulk mail today, the following suggestions can help.

1. Take advantage of the new x-Microsoft-Antispam header by creating an EOP transport rule. The following is an example of a rule that will mark messages as spam if the stamped Bulk Complaint Level is 6 or higher.

For detected messages this rule will set the SCL to 6 which will cause the message to take the spam action you have configured in the content filter. The additional header that this rule adds will make it easy to identify messages that were marked as spam by this rule.
For more information on rules that will increase the bulk sensitivity of EOP see Use transport rules to aggressively filter bulk email messages. This page describes three separate rules, the first of which walks through the creation of the above rule. I would recommend starting only with the first rule that looks at x-Microsoft-Antispam, and if you need even more aggressive filtering, create the subsequent two rules.

2. Educate yourself on the new X-Microsoft-Antispam header. See Anti-spam message headers and Bulk Complaint Level values.

3. Educate your users. If a user recognizes the sender of the bulk message and does not want to receive further mail, they can click the unsubscribe link on the email. If the user does not recognize the sender, they can block the sender or domain in Outlook or OWA by adding the sender to their Blocked Senders list.

4. Submit bulk mail and spam back to Microsoft for analysis. This allows us to continually refine our message filters. See Submitting spam and non-spam messages to Microsoft for analysis.

Note: EOP will always stamp this new header on messages regardless if it already exists or not. This prevents a spammer from manually adding this header themselves and setting a BCL of 0.

Going forward

In the near future it will be easier to take advantage of this new BCL system. We plan to roll this functionality into a slider that will be configurable in the Office 365 portal. Until this happens, creating the transport rule described above will allow you to take advantage of this functionality immediately.

Resources

The following TechNet documentation was updated in July 2014 to include information about the new X-Microsoft-Antispam header.

What’s the difference between junk email and bulk email?
Anti-spam message headers
Bulk Complaint Level values
Use transport rules to aggressively filter bulk email messages

Andrew Stobart

S/MIME in Office 365

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and digital signing of 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

1. .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.
2. 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 PowerShell cmdlets 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 PowerShell and 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 EAS to 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:

1. Public Key Infrastructure (PKI). You can use Active Directory Certificate Services to issue certificates to the end users.
2. 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.
3. 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:

1. 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.

UserCertificate is 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 PowerShell cmdlets 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 EAS to send and receive S/MIME messages.

Note: Make sure you check S/MIME Supported Clients section belowbefore 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. So, 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 (Contact) currently not supported.

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