EHLO, Ergo Sum

When Blocked Senders Go Bad

To ensure the safe and block lists work across all clients – Junk Mail MUST be enabled on the mailbox!

SPAM is war, but sometimes even when you do the right thing, blocked messages can still get through and make it to the inbox.

From the documentation and within Outlook itself, this doesn’t seem possible:

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/configure-junk-email-settings-on-exo-mailboxes?view=o365-worldwide#about-junk-email-settings-in-outlook

And from within Outlook:

There are cases however when this doesn’t work. Specifically if junk mail on the mailbox is disabled and if using OWA.

What does this have to do with the Outlook settings? Bear with me.

From the screen shot above, it would appear that junk mail is disabled. But that is not necessarily the case. That setting is referring to the Outlook junk mail capabilities – specifically – SmartScreen, which, despite being deprecated will still honor safe and blocked senders lists.

More importantly, choosing the other junk mail options from this dialog box does not *enable* junk mail on the mailbox.

https://techcommunity.microsoft.com/t5/exchange-team-blog/deprecating-support-for-smartscreen-in-outlook-and-exchange/ba-p/605332

So given all that, how would junk mail become disabled and how does OWA behave that is different than Outlook?

Lets look a few examples.

Test Case 1:

A mailbox that blocks this sender but junk mail is not enabled and using OWA.

A simple transport rule that bypasses SPAM checking for that same sender

Let’s trace it

See that? Despite the fact the sender ( its obfuscated, trust me!) is in the blocked sender list, this message was delivered to the inbox.

Image result for old man screams at cloud

Now let’s enable junk mail for this account:

Set-MailboxJunkEmailConfiguration adavid -Enabled $true

Message trace…

Boom! Now it works as expected.

As you can see, enabling junk mail is for an account is key and this doc backs that up:

https://docs.microsoft.com/en-us/exchange/antispam-and-antimalware/antispam-protection/configure-antispam-settings?view=exchserver-2019

So we now we know the ways junk mail can be disabled or enabled. Either via OWA or via PowerShell – but NOT from Outlook. And from what I can tell, it can NO longer be disabled via OWA either unless using the classic interface: https://outlook.office365.com/owa/?path=/classic

I don’t see – or can’t find that setting in the new interface

So there you go. If you find blocked senders showing up in the inbox, your first stop should be powershell and Get-MailboxJunkEmailConfiguration/Set-MailboxJunkEmailConfiguration to enable it if disabled!

Bottom line: To ensure the safe and block lists work across all clients – JunkMail MUST be enabled on the mailbox!

Note this works the other way as well – safe senders ending up in junk mail when it’s disabled. But this one seems to be the one that can annoy the most.

Sadly, there isn’t an easy button to force junk mail enabling on all mailboxes. A GPO can be used or walking through the mailboxes and enabling. It would be nice to have a simple global policy that could be managed as as admin to prevent it being disabled.

Where did my Remote Routing Address go?

Enable-RemoteMailbox is a powerful and useful command, sparing Exchange Hybrid admins the pain of creating and moving a local mailbox to Exchange Online. It does, however, have some issues occasionally – specifically when creating the required RemoteRoutingAddress.

From the official documentation, you get the provided example:

Enable-RemoteMailbox “Kim Akers” -RemoteRoutingAddress “kima@contoso.mail.onmicrosoft.com”

This usually works, however, from what I have seen, Exchange sometimes doesn’t treat the initial remote routing address as a distinct email address and it essentially disappears. It’s a bit quirky as Enable-RemoteMailbox doesn’t consume the EmailAddresses switch.

This is made more obvious in EAC, as the gui forces you to create the email address before it can be set as the Remote Routing Address.

If you have already created the remote mailbox, then you can run the command below to fix it up:

Set-RemoteMailbox -EmailAddresses @{add=”user@contoso.mail.onmicrosoft.com”} -RemoteRoutingAddress user@contoso.mail.onmicrosoft.com -identity <alias> -DomainController <FQDN of DC>

Another option is to run two separate Powershell commands when creating a remote mailbox. Note that the second one may fail if the DC you are connecting to isn’t aware of the remote mailbox object yet. You can get around this by using the same DC with the -DomainController switch or just waiting a bit and trying the second command again.

Enable-RemoteMailbox -identity <alias> -PrimarySmtpAddress user@contoso.com -RemoteRoutingAddress user@contoso.com -Alias alias -shared -DomainController <FQDN of DC>

You will notice I am setting the RemoteRoutingAddress to the primary SMTP address in the first command. I do that because you have to set it to something. I plan on setting that in the next step to the actual remote routing address.

I also like update the alias here as well to ensure it matches to the existing SamAccountName in Active Directory, otherwise you may find it set to the “User Logon Name”. Of course, you can set this to anything you want.

Both the -shared and -DomainController switches are optional and available in the latest supported Cumulative Updates for Exchange 2013 and above.

Once enabled, add the additional email address with the correct RemoteRoutingAddress.

Set-RemoteMailbox -EmailAddresses @{add=”user@contoso.mail.onmicrosoft.com”} -RemoteRoutingAddress user@contoso.mail.onmicrosoft.com -identity <alias> -DomainController <FQDN of DC>

The RemoteRoutingAddress can be anything unique. It’s typically “user@<tenant>.mail.onmicrosoft.com” and you should already have an existing On-Premises send connector to ensure messages are routed to the Exchange Online mailbox.

The remote mailbox now has the correct email and remote routing address set and, more importantly, they should stick! I have not tested this against Exchange 2019, but I would assume the issue is still there.

Happy Hybriding.

Go Commando when Scripting. Checking out the new Powershell Secrets Module.

Everyone loves a good secret and anything to make it easier to store that secret and keep it from prying eyes is worth looking at. With that in mind, I was immediately interested when I read about the release of the new PowerShell Secrets Management Module.

Note that the current module uses the built-in Credentials Manager, which apparently can be exploited. Nonetheless, I have found it useful and easy to use and there is the promise to use extensions, including Azure and other “vaults” in the future.

So, how do you get this to work?

First install the module from https://www.powershellgallery.com/packages/Microsoft.PowerShell.SecretsManagement/0.2.0-alpha1

Install-Module -Name Microsoft.PowerShell.SecretsManagement -AllowPrerelease

If you find it’s not installing or loading correctly, be sure to update the local PowerShellGet module. I found that I also needed to install the latest .Net version. After that, things worked as expected.

Now add the password/secret to the Credentials Manager on the local machine via the new module. Remember you are adding this in the context of the current user, so only the logged in user will have access to it.

Add-Secret -Name Test -Secret Secret

In the example above the secret is….well, Secret and the name is Test. Clever, right?

You can view it a number of ways:

Get-Secret -Name Test
System.Security.SecureString

Get-Secret -Name Test -AsPlainText
Secret

Get-SecretsVault

Name ModuleName ImplementingType
—- ———- —————-
BuiltInLocalVault

From the Credentials Manager on that machine, you can see it as well:

Let’s assume you have a script that needs a name and password to authenticate to the local domain. You could pass that new secret easily in this really basic example. (Again, running in the context of the user account on the local machine where you created the secret)

$User = “domain\User1”

$Pwd = (Get-Secret Test)

$UserCredential = New-Object System.Management.Automation.PSCredential ($User, $Pwd)

Get-ADUser -Identity <user> -Credential $UserCredential

Pretty nifty, right? All I had to do was grab the password on the fly from the vault using Get-Secret.

Anyway, that’s it. Not much to get it to work, but lots of potential. I am looking forward to using this module as it matures.

Renewing that pesky “Microsoft Exchange” certificate

You know the one I am taking about. The self-signed certificate with a friendly name of “Microsoft Exchange” that each server issues by itself to itself. They are valid for 5 years , then suddenly, they are not. When on-premises was king, you rarely saw any questions about these. They just worked – and as companies upgraded, new ones were created on the new version servers, mailboxes were moved and the old certificates disappeared as the servers were retired.

Today, as more migrate to Exchange Online, these old 2010/2013 servers seem to be kept around longer during the migration, frozen in time and are now bumping into that 5 year certificate lifetime.

So why renew it? It doesn’t appear to be doing anything. Well Sir or Madam, that is the certificate bound to the “Exchange Back End” IIS site and essentially secures all the internal communications.

If it expires, you could start experiencing the following side effects:

Dizziness

Dry Mouth

Exchange Powershell errors

Inability to open EAC

Errors in the event logs such as :

See that :444? That’s the backed port number

To fix:

NOTE: Some have mentioned in the comments below that these steps also removed the IIS service from the public SSL certificate. To fix: Once done: Reassign IIS to the public cert…In other words, the 3rd party certificate clients use to connect to Exchange…

First, simply renew the certificate. You can do this in Powershell or EAC by highlighting the “Microsoft Exchange” certificate and clicking Renew.

Second, you’ll want the server itself to trust this new self-signed certificate. Nicely enough, the original Exchange setup program does this for you. When you renew the self-signed certificate, not so much. Once that new certificate is created, open MMC and add the Certificates snap-in on that server. From there, choose the “Computer Account” and then “Local Computer”.

Copy the new certificate from Personal/Certificates to Trusted Root Certificate Authorities/Certificates. If you access the properties on the new certificate and go to the “Certification Path” tab, it should show as OK.

Third, add the new certificate to the Back-end Binding and run IISRESET.

From the article I first linked above. Do the following:

Start IIS Manager on the Mailbox Server.
Expand Site, highlight Exchange Back End, and select Bindings from the Actions pane in the right side column.
Select Type https on Port 444.
Click Edit and select the Microsoft Exchange certificate.
From an administrator command prompt, run IISReset. ( Do this off-hours if this a standalone Exchange Server. If you are using a DAG, then move all the databases to other servers and have at it)

You’ll go from this:

To this:

You are done for another 5 years.

Authenticating trusted messages with Exchange and Office 365

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. If 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. And 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 white-listed 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.

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.

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.

About Me

Hello Friends. Andy David here. I’ll be posting things that I find interesting and maybe you will too. Expect stuff about Exchange, Office 365, AD, SharePoint and who knows what. I don’t plan to write extensive “How-To” articles. There are plenty of those. Instead, look for the USA Today/SkyMall version of things. If you have a short attention span, this is the place for you!

I have been using Exchange since 4.0 debuted some 20 years ago. I built my first NT AD Domain then as well and named it “Domain”, not knowing any better. Doh.

I have been an Exchange MVP since 2002. I also had the honor of naming “You had me at EHLO” for the Exchange Product Group Blog way back in the early 2000s.

I attempt to answer questions in a number of places:

https://docs.microsoft.com/en-us/users/andydavid/

https://www.reddit.com/user/adavid1608

https://techcommunity.microsoft.com/t5/user/viewprofilepage/user-id/86

and can be found on Twitter:

Tweets by adavid6