Safe Senders, Spoofing and Office 365. They really can be friends!

One of the rather interesting side effects of moving your mailbox to Exchange Online is the change in behavior of the old trusty Safe Sender list. As Terry points in this blog post from last year, if your mail client trusts only messages sent from a safe sender, all other messages will end up in junk mail. This is change from on-premises – where only messages marked as junk will be marked as SPAM. All others – including the trusted senders- will arrive in the inbox.

For the most part, this is not a big deal, simply inform your end-users of this change once their mailbox has been migrated and let them decide how to handle it; Keep using Safe Senders and whitelist any legitimate senders, or disable it and use the standard junk mail settings in the client.

There are specific scenarios where this could be problematic however. Many organizations have developed internal processes that send reports, alerts and updates anonymously from on-premises systems to their workforce. It’s very common to have dozens to hundreds of these processes, enabled over many years – each sending as an arbitrary SMTP address – essentially spoofing as an authoritative domain.  As I discovered, it’s not as easy as it sounds to ask end-users – especially executives (who rely heavily on the Safe Sender option) to whitelist numerous addresses when it wasn’t required in the past.

Ah, the solution is easy. Just add your authoritative domain to Safe Senders. That will cover you for everything. Not so fast!

One, you can’t add an authoritative domain to the trusted list.

Two, Exchange Online doesn’t honor whitelisted domains anyway.

One possible solution that is the least disruptive to the end-user: Trust those internal processes at the Exchange server level.

Example: Assume you are in hybrid mode and still have an Exchange Server on-prem. Create a receive connector on the Exchange Server. Scope the remote IP addresses to the internal SMTP servers that send these messages to end-users, then check the box ( or use powershell) to set the receive connector you just created as “Externally Secure”.

The receive connector auth and permissions will now look like this:

AuthMechanism           : Tls, ExternalAuthoritative
PermissionGroups        : AnonymousUsers, ExchangeServers

 

What you see in the headers of a received message:

X-MS-Exchange-Organization-AuthAs: Internal

X-MS-Exchange-Organization-AuthMechanism: 10

In the end, all messages that pass through this connector ( and eventually through the hybrid connector to Office 365) will be considered authenticated and will not be sent to junk mail – even if the sender is not in the Safe Sender List. Boom!

P.S. This is only an example. Do not enable this option if you do not trust or have control of the sending servers.

 

 

 

Abs of Steel and My DKIM Body Hash Won’t Verify. Help Me Dr. Phil!

If you are applying an *inbound* disclaimer with a mail flow rule in Office 365, you may be surprised to see a DKIM body hash failure in the header of the message. ( and if you have never noticed this, well, that’s understandable!)

Example:

 

Message sent from Gmail with disclaimer rule:

 

Authentication-Results spf=pass (sender IP is 209.85.216.180) smtp.mailfrom=gmail.com; contoso.com; dkim=pass (signature was verified) header.d=gmail.com;contoso.com; dmarc=pass action=none header.from=gmail.com;contoso.com; dkim=fail (body hash did not verify) header.d=gmail.com;

 

 

 

 

Message sent from Gmail w/o disclaimer rule:

 

Authentication-Results spf=pass (sender IP is 209.85.220.173) smtp.mailfrom=gmail.com; contoso.com; dkim=pass (signature was verified) header.d=gmail.com;contoso.com; dmarc=pass action=none header.from=gmail.com;contoso.com; dkim=pass (signature was verified) header.d=gmail.com;

 

This brings up some interesting questions. Is the DKIM check *after* mail flow rules are processed? And does this mean I have lost the ability to check for DKIM failures for those messages?

Thankfully, no on both. I have confirmed that you can ignore the failure and have been assured that mail flow rules are evaluated after DKIM verification.

As you can see in my examples, in both cases, the first DKIM check passes and just as importantly, DMARC passes and that is what you should be hanging your hat on.

Stay safe out there!

Designing My Office 365 Tenant for On-Premises

With the new Exchange Online storage limits, I got to thinking what that would look if I were to do this on-prem.

Let’s see, 2GB mailboxes to start… 100GB max sixe – no archive ( Why would I need an archive?)…16,000 mailboxes. Follow the Preferred Architecture otherwise: DAG, 4 copies of the databases, one lagged, JBOD, etc…

Run that through the latest mailbox calculator and wait for the big reveal.

 

Twelve Mailboxes per Database!

 

144 Databases in the DAG. I can handle that. Yes, 12 mailboxes in each. Got it.

Much less RAM than you might think. I have never considered using a “Lagged Copy Server” though.

Ouch. These giant mailboxes will need a bunch of storage! Not sure I am comfortable with databases that size. I am beginning to lose my nerve.

I think I will take the third option and leave the 100GB mailboxes to the Exchange Online professionals. You know who you are.

 

Auto-Forwarding is not dead. It’s very happy!

Auto-Forwarding from Exchange. Now there’s a subject that has been beat to death. We all know how it works and it has certainly been documented enough don’t you think?

Posts from Tim and others are worthy reads. My goal here is to simply put all of this together and maybe point out some things you may not know.

There have traditionally been two options to forward from Exchange: Outlook Rules or Administrator-enabled forwarding.

  1. Outlook Rules: End users have 3 options as illustrated in the image below. Of course, only one can be chosen, but I have checked all three to point them out. Additionally, you can select an existing user from the GAL or contacts or enter a SMTP address ad-hoc.  Regardless of which option in the rule is selected, the messages will be delivered to the user’s inbox.

 

 

 

2. Administrator enabled Auto-Forwarding:

This is done using EAC or Exchange Powershell.

In EAC, under Delivery options for the Mailbox.

Note here that the recipient has to exist in the Address Book.

With Powershell and set-mailbox, you have additional options:

The ForwardingAddress parameter specifies a forwarding address for messages that are sent to this mailbox. A valid value for this parameter is a recipient in your organization. You can use any value that uniquely identifies the recipient.

The ForwardingSmtpAddress parameter specifies a forwarding SMTP address for messages that are sent to this mailbox. Typically, you use this parameter to specify external email addresses that aren’t validated.

Set-Mailbox -Identity "John Woods" -DeliverToMailboxAndForward $true -ForwardingSMTPAddress manuel@contoso.com
 Note the important difference and the ability to include *or* exclude delivery to the mailbox.

How messages are delivered and forwarded is controlled by the DeliverToMailboxAndForward parameter.

  • DeliverToMailboxAndForward is $true   Messages are delivered to this mailbox and forwarded to the specified recipient.
  • DeliverToMailboxAndForward is $false   Messages are only forwarded to the specified recipient. Messages aren’t delivered to this mailbox.

Office 365 Outlook Web Access adds an additional wrinkle here. End-users have access to a trimmed down version of the administrator forwarding option.

This is not an Outlook rule, but similar to :
Set-Mailbox -Identity “John Woods” -DeliverToMailboxAndForward $true -ForwardingSMTPAddress manuel@contoso.com

 Of course, Office 365 users can still create rules for forward in Outlook as well.

 

Why you may not want to forward to external recipients

  1. Data leaks, typically unnoticed, to mailboxes you do not control.
  2. A forwarding rule could create a mail loop between your org and another.
  3. Forwarded messages could land your sending IP addresses on block lists.
  4. Forwarding could bypass your data retention requirements. *

 

Things you may not know about forwarding

*Outlook forwarding rules allow the message to bypass the sent items. Yep, that’s right. The rule is server-based and handled at the transport level. The messages will be in their inbox, but not the sent items folder . You can verify this with a message trace. The source context of the forwarded messages will be Transport Rule Agent. The exception to this is if the rule is run manually against existing messages. Those forwarded messages will be in the sent items. The header of each will look similar to this

If you are a Office 365 customer or run Exchange 2016 on-premises, you can mitigate this loophole.

 

A forward rule and a redirect rule do essentially the same thing except the forwarded message will not have a FW: in the header to indicate to the recipient that the message was forwarded. It will appear to have come directly from the original sender. Well, that’s at least what the official documentation says. From my experience, that is not entirely true. The FW: may not be in the header, but a recipient will be able to see the message was routed through another mail system. It may show “on behalf” or “via” your organization ( Google does this). And of course, if they check the internet headers, the real path will be revealed. Some recipient mail systems may even reject messages forwarded like this.  If the administrator sets forwarding at the mailbox level or a 365 user sets via OWA, it is essentially a redirect.

 

Preventing user auto-forwarding

  1. Block at the remote domain level: Set-RemoteDomain -Identity ExternalDomain -AutoForwardEnabled:$FALSE. This will stop the Outlook forwarding rules.
  2. For granular control, use a transport rule to prevent by group or user. Otherwise, block the default remote domain for auto-forwarding as above. This will also stop Outlook forwarding rules.
  3. Remove the ability for end-users to auto-forward in Office 365 OWA.

So there you have it. A compilation of the best of forwarding articles with some auto-tuning from me .

My recommendation: Block all auto-forwarding at all levels for users. Leave it to the professionals – your messaging administrators who can enable auto-forwarding at the server level.

I can’t think of too many business requirements for auto-forwarding, but I am sure there are out there.  I hope this little update helps you understand it some more.

 

Selectors: The Magic Sauce of DKIM

One question I see a lot is “How can I let 3rd party vendors send as our organization using DKIM?” It’s a lot easier than you think.

The trick is in the selector. Per RFC 6376 To support multiple concurrent public keys per signing domain, the
key namespace is subdivided using “selectors”.  

Implementing this is pretty straight-forward, so let’s get started.

 

Suppose you have your existing DKIM infrastructure handled by Office 365/ EOP.

When sending a message through Office 365/EOP, the header of the message is stamped with the required DKIM fields.

Check out the sample header in the received message below. Note the s=selector1. This tells the receiving server to check : selector1._domainkey.contoso.com.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=contoso.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qwJgpoXgR3MRDrSVO91kT+tYSpE//LjikNGicqlKjU0=; b=FnK8HjJFfEKHMq5EoIGJVzty4w+v7uE0UmQVFrVYr348e4tqfE66U/pZanlNfS7guhj2T5g5sqva7w1Wc1/+NOlC6CEBMrQiuFVDo0Akk8narhX9r9xs99Yniv…

 

In your organization’s external DNS, you have a CNAME record of that selector:

selector1._domainkey.contoso.com    canonical name = selector1-contoso-com._domainkey.contoso.onmicrosoft.com

Following the DNS pointer…

In the Office 365 DNS is something like this text record with the public signing key:

selector1-contoso-com._domainkey.contoso.onmicrosoft.com       text =

        “v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBFDKKLKLKGNADCBiQKBgQDLODjPzMtm1EVPXU3OgPWgW+ABPqDtoHLnzmyTXdl+abC5M13ZovMLIrTbEJTT…

The receiving server can now run it’s calculations against the message knowing the public signing key.

So you can see where we are going with this.

If you want a 3rd party vendor authorized to send as your company and apply a DKIM key to each message, you have a few options:

Create a unique selector CNAME – different from the one you use for messages coming from your organization – in external DNS that points to the 3rd party vendor’s DNS which contains the public DKIM signing key. This is similar to what Office 365 tenants do.

or

Use a unique selector and create the DNS text record that has the public DKIM signing key provided by the vendor. Remember: They are generating the messages, so the 3rd party vendor has the private key, you do not!

 

Each method will work and it’s really up to you. Note that if you decide to create the text record in your DNS with the public key signing key, it will break DKIM for those messages if the 3rd party vendor decides to change the private signing key that they hold.

I think it goes without saying that the one thing you don’t want to do is provide “your” private signing key to a 3rd party vendor and have them sign messages using your “regular” selector – the one you use for messages that actually do come from your domain. At least I wouldn’t recommend that.

Once this is all setup, then it’s up to the 3rd party to set the selector correctly in the message header. So, if EOP is stamping “selector1” on all outbound messages, the 3rd party vendor can use anything allowed by RFC except selector1.

As an example, headers received from the vendor, sending as you, may stamp it with:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=contoso.com; s=contosoBULK

Receiving servers will now check the text record: contosoBULK._domainkey.contoso.com and depending on how you set it up, obtain the public signing key or get redirected by CNAME to another DNS.

This also works great for subdomains – i.e. have the 3rd party send as mail.contoso.com and setup the DKIM records for that specific SMTP domain.

There is no real limit to the number of selectors one domain can support, just ensure they are unique to each sender and are configured properly so receiving systems can correctly access the DKIM public signing key.

With the advent of so many cloud services, I suspect just about every organization has at least one 3rd party sending as their SMTP domain, so get your DKIM ( and SPF records!) right. I hope this helps understand that process a little bit better.

For more info about DMARC/SPF and DKIM:

The Trinity of Email Protection: Lessons Learned using DMARC, DKIM and SPF in Office 365

The Trinity of Email Protection: Lessons Learned using DMARC, DKIM and SPF in Office 365

I am a big fan of DMARC and its ability to easily determine which messages sent as, and from, your SMTP domains are using authenticated and authorized servers. The A in DMARC actually stands for “authentication”, but it’s really a little of both.

Regardless, it’s something I highly recommend and if you are using Office365/EOP, there is really no reason you should not be using it, after all it’s already enabled. In fact, if you choose not to set up any of the email protection trinity, EOP will absolutely mark any message sent from the internet as your domain to your domain as SPAM.

Since you are reading this, I assume you are using it or wanting to use it. To that end, here are some tips and lessons learned from my own experiences:

  1. Start small.  Your first DMARC record in DNS ( _dmarc.contoso.com) should do nothing but report. At its very minimum, it should look like this: “v=DMARC1; p=none;rua=mailto:DMARC@contoso.com;”  All this does is tell recipient servers that they should send DMARC failure reports to DMARC@contoso.com ( This could be a mail-enabled Public Folder).  The p=none does not affect the way messages are delivered. With p=none, you are not suggesting to a recipients mail server that they change the way they handle the messages that fail DMARC checks.  I would recommend you always use p=none, unless you have no 3rd party vendors that send mail as your SMTP domain. In that case, p=quarantine is probably worthwhile once you have vetted out your DMARC policy sufficiently. I would never use p=reject  – unlike a few ISPs out there.
  2. Get your SPF records in order. If you have 3rd party vendors that send as you, this is especially important. It doesn’t take much to exceed the 10 Lookup Max on SPF records. Heck, if you are using EOP, spf.protection.outlook.com requires three lookups alone! Exceeding that amount can cause failures because recipient domains may ignore your SPF completely.
  3. Don’t forget DKIM! SPF seems to get all the attention, but setting up DKIM could not be easier in Office 365. You can even configure it in the portal now under the Protection menu in EAC. And once setup, there is nothing cooler than seeing that DKIM-Signature in the headers.
  4. There are options if you simply can not get those SPF lookups below 10. The SPF RFC supports macros. Mind. Blown. No really. Imagine a SPF record of “contoso.com IN TXT “v=spf1 include:%{i}._ip.{%h}._ehlo.{%d}._spf.contoso.com –all”.  Ok, I am not aware of anyone that does this, but it’s a possibility. Another option is not use SPF records and depend on the DKIM record. This is great if you have no or cooperative 3rd party vendors that send as your domain. DKIM is not limited to that pesky 10 max record lookup and as mentioned above, DMARC messages need to pass either the DKIM or SPF and, not both. If you support multiple SMTP domains, you may want to also consider setting up distinct SPF records for each zone rather then using the include option to keep each domain under that 10 limit.
  5. Don’t forget the alignment requirement! As mentioned above, DMARC will check the sender’s valid SPF or DKIM records in DNS. If one or both of those exist and pass, then alignment must pass as well. This is the magic sauce in DMARC. Alignment simply means the header FROM: matches the Domain “from” (i.e. the MAIL FROM: /Return-PATH) of the message. This is an important consideration because even if the message passes the SPF or DKIM check, it can still fail DMARC if for some reason you have processes that set the FROM: in the header to a completely different domain from the RETURN-PATH or MAIL FROM:. I have seen it happen!
  6. Leverage DMARC inbound. The value-add for DMARC is pretty obvious for messages sent out from your org. But the really cool part is using it inbound to stop those endless spoofing attempts without the need for clunky transport rules. You can create nifty rules to check for failures as illustrated in a previous blog post. This is another reason you want those SPF records to be below 10 lookups. If they exceed allowed amount, you may find that your inbound rules do not correctly detect the dmarc=fail or dmarc=pass.
  7. Whitelisting is your friend. If you are going to create inbound DMARC rules, it is very important to remember that SPF lists mail servers that are authorized to send messages on behalf of your SMTP domain. That’s not necessarily the same list of IPs that will sending as your domain directly to internal users. If you are using WorkDay, SalesForce or any of the multitude of SAAS cloud vendors, you can be pretty darn sure they are sending spoofed messages to your domain, but not to external recipients as you,  so they wont be listed in your SPF. Any whitelisting rules MUST be above the DMARC rule. Seems obvious, but don’t overlook it!
  8. Add a check for dmarc=temperror in your inbound transport rule. If the domain in the Mail FROM: doesn’t exist, you may see a spf=temperror or dmarc=temperror in the Authentication-Results header of the message. If your rule isn’t testing on that, it could slip past your defenses. I have actually seen a number of these from images spun up in 3rd party hosted solutions. I prefer to tag these as FAILs, but that is up to you if you want to let them pass.
  9. Set the inbound rule to only notify you initially. As with DMARC in general, start small. Don’t block anything until you feel confident that only the truly unwanted spoofed messages are trapped. Your initial rule should simply check for a DMARC failure, and send an incident report to a mailbox that you monitor. An example rule is found here. And that leads me to the next tip once you ready to take action on DMARC failures.
  10. Quarantine the message, do not simply set it to a high SCL. You really have two options  ( I would not delete the message) on how to deal with illegitimate spoofed mail, you can force it the quarantine, or set it at a SCL high enough to mark it as SPAM. I recommend forcing it the quarantine so that end-user safe sender lists can not trump your rule.  If you have a user that has added a GAL object to their contacts ( A very common scenario), and has also checked “Also trust e-mail from my contacts” in Safe Senders, the spoofing rule will be defeated.
  11. Add a custom x-header to your rule. This helps you, the help desk and the end-user easily identify why this message was quarantined.

So there are some tips. This is by no means a comprehensive list. I plan to add more or revise these as time permits. If you want to read more, including how to setup DKIM in Office 365,  I would suggest following the blogs of Terry Zink  and Andrew Stobart.

 

 

On-Premises Mailbox Missing Retention Policy Tags after enabling Archive in Office 365

Consider the following scenario:

You have an on-prem mailbox, but decide to move your online archives to Office 365 to take advantage of the “Unlimited” storage. No problem. That works great for existing mailboxes, but when creating new archives in the cloud, you discover that the policy retention tags are not surfaced to the end-user in Outlook and the ability to archive to a pst remains.

AutoArc1

You have a few options:

Run: Start-ManagedFolderAssistant <user>

If that doesn’t work, move the online back on-premises and run Start-ManagedFolderAssistant.  Alternatively, if the archive is unused, disable it, re-enable on-prem  ( and run Start-ManagedFolderAssistant to speed things up). Once the policy tags appear, move it back to Office 365.

P.S. Ensure you have imported all the on-premises tags to Office 365 per the link below. Otherwise the automatic archiving will not work!

https://technet.microsoft.com/en-us/library/jj907307(v=exchg.150).aspx

 

 

 

 

 

On-Premises mail-enabled Modern Public Folders are not visible in the GAL from Office 365 Mailboxes

Just a reminder. If you are in hybrid mode and using public folders on-premises, the mail-enabled PFs will *not* be visible via the Outlook Address Book for 365 mailboxes – even if they are not hidden from the GAL. All you will see is:

Capture2

This also means the display name will not be resolvable when creating or receiving a message from the folder.

One work-around is described here under the section “Configure Directory Synchronization” that allows you to create mail-enabled contacts in 365 that represent the PFs.

In the meantime, you will have to wait for one of two solutions:

  1. True mail-enabled PF synchronization.
  2. Supported Modern Public Folder Migration to Office 365. ( Yea, that’s right  – The migration of 2013/2016 Public Folders to Office 365 is not supported right now.

 

 

 

Transport Rules versus Safe Sender Lists in Office 365/EOP: ¿Quien es mas Macho?

One of the great powers of being the messaging guy or girl is the ability to create transport rules in response to business requirements. Seemingly subtle differences in the rule’s logic, however, can make a huge difference.

For example: You craft a rule to block spoofed messages from the internet that appear to come from your SMTP domain. Like all good internet citizens, you have enabled DMARC, so you construct a rule like this:

Capture2

 

So, what happens to the message when the rule is applied? Since you are setting the SCL to 9, it will end up in the quarantine by default . Or will it?

Consider this: Since you are marking the message as SPAM, you are also giving the end-user the ability to bypass that rule by whitelisting the sender.

Because EOP honors both the RFC 5321 MAIL FROM: and the RFC5322 FROM:, if the MAIL FROM: just happens to be on an user’s safelist – added through Outlook or OWA – the message will be allowed,  even if the FROM: is a spoofed domain.

If you don’t like the prospect of messages potentially slipping through without hitting the quarantine first, force it instead:

Capture5

Problem Solved!

Well, maybe. Since you are pushing the message to the quarantine by rule, the end-users will not see the messages in their personal quarantines and will not be able to release the message without administrator intervention as documented here:

https://blogs.technet.microsoft.com/eopfieldnotes/2014/08/28/behavior-change-when-setting-the-scl-with-a-transport-rule/

But maybe that is what you want.

Regardless, you can craft the rule to meet your needs. And options are always good.