Email loops – what happens, when, and why.

The following headers are preserved, unmodified, by all default Exchange implementations:

  • X-MS-Exchange-Inbox-Rules-Loop
  • X-MS-Exchange-Transport-Rules-Loop
  • X-MS-Gcc-Journal-Report
  • X-MS-Exchange-Moderation-Loop
  • X-MS-Exchange-Generated-Message-Source
  • X-LD-Processed
  • X-MS-Exchange-ForwardingLoop
  • X-EOPAttributedMessage
  • X-EOPTenantAttributedMessage

X-MS-Exchange-Inbox-Rules-Loop

This header represents the number of times a message can be redirected, forwarded, or processed by an automatic-reply. In Nexus365 this is set to only allow this to happen once. On-premises installations of Exchange allow up to three instances of redirection, forwarding, or auto-response before stepping in to prevent mail from looping.

When viewing headers the giveaway looks like this – if the value is 1/1 then the message will be silently dropped:

Source: MAILBOXRULE
event_id: THROTTLE
reference: XLoopHeaderCount:1/1

X-MS-Exchange-Transport-Rules-Loop

This header is set if mail is redirected, or recipients are added, via an Exchange transport rule. This also has a limit of one.
In this instance the sender would receive a non-delivery report message sent back to them with this in the explanation:

550 5.7.128 TRANSPORT.RULES.RejectMessage; Transport rules loop count exceeded and message rejected.

X-MS-Exchange-Moderation-Loop

You’ll only see this header when a message has been forwarded for the purposes of approval – in such circumstances the header will include the arbitration mailbox’s email address. Since there is a limit of one for this header type the approval message will be silently dropped if this header is already found to be present.

X-LD-Processed

Used internally by Microsoft to detect looping on a per-tenant basis, permitting up to three loops per tenant for either an external email address or a forwarding address.

X-MS-Exchange-ForwardingLoop

Present when forwarding is set on a mailbox. If the mailbox is set to deliver-and-forward there will be two copies of the message: one in the local mailbox and one sent externally via the forwarding address. The forwarded message will include the GUID of the original recipient’s tenancy, and the original email address:

X-MS-Exchange-ForwardingLoop: user@ox.ac.uk;<guid goes here>

This header allows the system to detect loops where an email is forwarded and the destination recipient has another forward which sends it back to the source.

X-MS-Exchange-Generated-Message-Source

This checks for loops in system-generated messages, which is only used if an auto-reply via an inbox rule is in effect. The following headers are stamped:

X-Auto-Response-Suppress: All
 X-MS-Exchange-Inbox-Rules-Loop: user@ox.ac.uk
 auto-submitted: auto-generated
 X-MS-Exchange-Generated-Message-Source: Mailbox Rules Agent

X-EOPAttributedMessage

Shows how many times the message has been processed by the Exchange Online Protection process in that tenancy. This value is reset if a message is forwarded from one tenancy into another. The precise value at which the message will no longer be processed is variable, and subject to change, but Microsoft currently state that the total hops permitted is seven, or three within one tenant’s environment. If that value is exceeded the following SMTP response will be sent (with ATTR1 for the total hop limit, and ATTR34 for total hop limit within a tenancy):

554 5.4.14 Hop count exceeded - possible mail loop ATTR1

Should the ATTR value be 39 or 40 we can log a support ticket with Microsoft to look into if the issue is with quarantine or spam-processing.

Posted in Uncategorized | Leave a comment

Last call for Calibri as Microsoft’s default font.

Microsoft have announced that Calibri will no longer be the default font in their applications. Those of you with long memories may recall that Calibri replaced Times New Roman as the default way back when Office 2007 was first released. Now they’ve decided it’s time for another change.

The new font is merely taking over default duties where Calibri is the incumbent, such as with Microsoft’s 365 apps. Whichever new font ends up declared as the winner will replace Calibri in that role.

To answer some of the queries:

  • Calibri will remain available as an option – it’s being demoted, not removed entirely.
  • Office 2019 will display these fonts natively. For correct display in older versions of Office apps you should embed the fonts in the options of the ‘save’ dialogue box.
  • Segoe UI will remain the font-of-choice for Microsoft’s Windows and Web UIs
  • You may need to enable ‘optional connected experiences’ in your Office apps to make the new fonts available to you.

There are five contenders and, if you want to influence the decision, you have a chance to do so here.

The choices are shown in the graphic below. Sadly, despite a few wags already suggesting them, Times New Roman, Wingdings, and Comic Sans are not going to make the cut as the new default.

You can read more about these fonts, their designers, and their inspirations, here.

Posted in Uncategorized | Leave a comment

Block BCC messages sent to distribution groups

By default inbox-processing rules don’t process the BCC line, for privacy reasons. This means that if you have a carefully-crafted rule in your mailbox to divert Distribution Group messages to a subfolder, the rule won’t work if someone’s doing a reply-all via a BCC.

However Microsoft’s Exchange Team have now come up with a new powershell cmdlet which can resolve this behaviour. They’ve introduced a new ‘blockbcc’ switch to the set-distributiongroup cmdlet. Once set this will ensure that anyone trying to reply to a group via BCC will get a non-delivery report saying that they’re not allowed to do that.

It has user-friendly text:

The group [distribution group name] doesn’t accept messages sent to it as a BCC recipient.
How to fix it:
The message wasn’t delivered to the group because it doesn’t support sending to it as a BCC recipient. To fix this, try one of the following:
-Remove the group from the BCC adress box and add it to the To or the Cc box instead.
-Ask the owner of the group to change the setting to allow sending messages to it as a BCC recipient.
This bounce message only applies to the group or groups mentioned here. Unless you’ve gotten other bounce messages for other recipients, anyone else you sent the message to should have received the message’.

 

From a Nexus-team perspective, we need to do the following PowerShell to make this happen:

Set-DistributionGroup -Identity [group's name] -BlockBCC $true

Or to check:

Get-DistributionGroup -identity [group's name] | fl BccBlocked
Posted in Uncategorized | Comments Off on Block BCC messages sent to distribution groups

TLS 1.0 and 1.1: Last call!

I wrote on this subject back in July 2018 but, after a number of extensions to the deadline, the plug is finally being pulled on these outdated and insecure protocols.

Microsoft are now under way rolling out updates that will prevent acceptance of email connections from external sources using TLS 1.0 or 1.1. Nexus365 will NEVER use those versions of TLS to send secure outbound email.

It’s important to be aware that Nexus365 uses TLS opportunistically – email which does not use encryption (or if the TLS negotiation fails) Exchange Online will still accept messages unencrypted (if the sending server permits this). Likewise for outgoing email, if the receiving server does not issue a STARTTLS response.

Nexus365 will always attempt to negotiate the highest possible version of TLS which the communicating server supports. Once negotiated in the handshake, that TLS level will be held for the duration of the connection. Should TLS fail Nexus365 will not renegotiate a lower standard: delivery will instead be reattempted without TLS.

If you believe that TLS is the cause of any message-delivery issues, please let us know the SMTP errors logged (for example: “TLS negotiation failed with error SocketError”) and in particular the version of TLS being attempted from the protocol field.

 

Posted in Uncategorized | Comments Off on TLS 1.0 and 1.1: Last call!

Multifactor authentication: where next?

Now that the University is beginning to roll out multi factor authentication (MFA) it is worth reviewing the reasoning behind it, and what future authentication might look like for staff and students at Oxford.

Bear in mind that I’m not critiquing the concept of MFA here: it is a vital step to improve security at a time when Universities are being actively sought as a hackable target, with potentially huge rewards for the malicious. So what I’m writing about here is considering the best second-factor one should use, of all the available MFA options.

By far the easiest way to compromise someone’s account is social engineering – persuading a user to volunteer their information. Adding a second factor, beyond just a password, adds complexity and challenges for the nefarious. It’s far less likely that a user will be persuaded. More specifically it also ensures that both password and MFA have to happen at the same place and time, returning some semblance control to the legitimate user even when their password has been compromised.

“…the rate of compromise of accounts using any type of MFA is less than 0.1% of the general population.”
Alex Weinert (Director of Identity Security at Microsoft.)

TL;DR: You should use an authentication app on your preferred device.

Here’s why:

Text Messages
The underlying design of SMS has no capability to add encryption or verification. The need for backwards compatibility on billions of existing users’ devices, and vendors choosing to cease providing software updates after a couple of years, means that retro-fitting improved security can’t be done. The hardware to spoof a number is already out there, SMS signals can be intercepted, and it’s conceivable that anyone within range of a compromised user’s phone could generate fraudulent texts directed at that individual, or redirected elsewhere. SIM-swap fraud, where a ne’er-do-well impersonates you, to obtain a Porting Authority Code (PAC) to steal your phone number, is already a fairly common tactic.
The message size limit of 160 characters, roughly halved for some encoded languages, also limits the amount of information which can be transmitted at a time. And, finally, SMS lacks a mechanism to confirm delivery, or retry: messages can be delayed in transit or simply lost entirely.

Phone call
The public switched telephone network (PSTN) is similarly vulnerable: no encryption and no simple way to add any. The same issues of number spoofing exist and eavesdropping on a call is not beyond the capability of the determined criminal. The simplicity of the telephone system, based on well-known international standards, make it vulnerable to a whole host of attack vectors. Phone redirection is also simple and easy in most organisations, and is not (yet) widely recognised as an attack vector: it may be easier to socially engineer a telecoms department to get a user’s phone calls sent elsewhere. It’s probably that this could be done without the eyebrow-raising that asking for a password would provoke.

Hardware tokens
These are far more secure than PSTN or SMS second-factor authentication but have to be purchased. And if their security is ever compromised in the future it’s next to impossible to resolve that without simply having to replace them en masse.

App-based auth
The authentication app can take advantage of encryption and security features that are simply absent from the other authentication methods, and it’s updateable as new threats, or future vulnerabilities are discovered. Microsoft have already updated their authentication app several times this year – Microsoft’s Alex Weinart again:

“In just the last year, we’ve added app lock, hiding notifications from the lock screen, sign-in history in the app, and more – and this list will have grown by the time you plan your deployment, and keep growing while SMS and voice keep sitting still.”

 

 

Posted in Uncategorized | Comments Off on Multifactor authentication: where next?

Teams Telephony Trial

Microsoft Teams has slowly been taking over all of the functionality that was previously reserved for Skype. And I’m delighted to be able to say that we now have a very limited trial running that enables Nexus365 users to make calls to fixed landlines, mobile phones, and other conventional phone numbers.

For the purposes of this trial we have purchased 15 licences (all of which have been allocated: sorry!)

For users on the trial:

Once enabled for calling your Chorus phone number will be diverted to Teams. Please be aware that this will have the effect of removing any pre-existing Chorus forwards you might have in place.

The Teams client will now have a dialling pad on the ‘calls’ tab.

You can dial either by clicking the numbers on screen, by typing a number, or by entering a name that’s known to the system: it can resolve a name to a number.

The ‘History’ tab shows all your calls, inbound and outbound, and the ellipsis button on the far right gives you a menu including options to either add callers to your speed dial, or to block them.

The ‘Voicemail’ tab will show any messages which have been left, with an automatically generated transcription of what the caller’s message is. Of course you can also play back the message from here too: 

 

From the server-side we also have some great diagnostic tools to troubleshoot call-related issues:

I’m liking this functionality very much, particularly now that we’re enabling MultiFactor authentication – it’s wonderfully simple to receive a second-factor phone call from within the Teams app I’m already logged into, rather than search for a text message, look up a code on a hardware dongle, or install an app on another device.

 

Posted in Uncategorized | Comments Off on Teams Telephony Trial

Teams Cautionary Tale

This is a reminder that personal chats within Microsoft Teams should NEVER be used to store essential business data.

This follows a report in The Register that, due to a policy being mis-applied globally instead of individually, KPMG staff mistakenly had their personal chat histories irrevocably erased.
Only personal chats were lost according to the article, not chats conducted as part of a Teams meeting or Teams channel, and not any files uploaded to personal chat threads. Although the circumstances that caused this issue are highly specific, and our processes make it unlikely that it would be repeated at the University, unfortunate accidents and mis-clicks can happen to anyone in any organisation at any time. It is never wise to be complacent.

For this reason it is important to set user expectations that personal chat data should be treated as ephemeral, rather than permanent: there are limited options to recover it.

Posted in Uncategorized | Comments Off on Teams Cautionary Tale

Teams and sidebar pinning

Microsoft have reported an issue which is affecting a number of their education tenancies, including ours. The issue is that when a user pins an app to their sidebar in Teams it may be removed automatically. Affected users sees a message like the one below:

 

However the management setting in our administrative console is set to ‘Allow User Pinning’ – this is not happening because of an administrative decision taken by the Nexus Team, and has not been set in any of our App-related policies. Other Universities have reported the same issue and are working with Microsoft to resolve this.  Microsoft support staff have said:

“I have reached out to the engineering team regarding the case and have found that this has been already noted and the team is actively working on the issue. This behaviour is found with most of the EDU tenants. I’m glad to tell you that a fix for this is already being developed and would be in future releases for teams.”

 

 

Posted in Uncategorized | Comments Off on Teams and sidebar pinning

Covid19: VPN optimisation for Nexus365

If you’re not using the central University VPN for your Nexus365 users you may be concerned about the load on your VPN from self-isolating remote workers.

VPN server load can be drastically reduced by ensuring that Nexus365 traffic is NOT routed over your VPN connection and is instead sent directly to the cloud service. To do this requires global routing to be disabled in the VPN’s configuration, limiting the traffic routed through the VPN’s tunnel to internal-only content. In Cisco’s VPN client this may be as simple as ticking a box.

To allow VPN-server-side direct internet routing for Nexus365 only, Microsoft provide a Powershell script which can be used to identify the current IP ranges used by their services and another for URL/IP/Port information. Microsoft’s suggestion is that you use their API which queries Microsoft Service Endpoints, which can also be queried via script.

By making this configuration change you can ensure that even with a significantly higher number of remote workers, the amount of traffic using your connection is limited to essential-only.

Posted in Uncategorized | Comments Off on Covid19: VPN optimisation for Nexus365

Nexus365 and Covid-19 Coronavirus

Microsoft have made plans to ensure service continuity should their staff be affected.  There are currently no known impacts to Microsoft 365 services
Heightened awareness is in place for the following areas:

Service scale and operations – One of the benefits of a cloud service is the ability to scale dynamically, including utilisation of supply chain, reallocation of resources between services, and redistribution of load.Microsoft have already seen an increase in the use of Teams to which they have responded.

Supporting systems – A general principle of cloud service operations is remote management and administration.  Microsoft anticipate no effect to their ability to manage the systems used to support Microsoft 365, and have confirmed adequate capacity for staff to work remotely at scale.

External systems – Microsoft are working across industry with a focus on networking infrastructure. They are seeing some utilisation issues with public ingress / egress to China, but otherwise there are no issues identified.

Impact to location –Microsoft’s services are designed for remote administration; however, with the recent news that the Seattle area represents a higher incidence of COVID-19 they have provided specific details around support of the service should Microsoft engineers be constrained to work from home. Microsoft employs a security first approach to administering Microsoft 365 service.  Each engineering resource that is accountable for managing the service has the ability to securely administer the service without direct access to the corporate location. Microsoft maintains multiple geographic locations outside the Seattle area with individuals who are capable of maintaining and managing the service.

People – As the largest provider of commercial services Microsoft have the capability of ensuring continued operations with multiple subject matter experts in each discipline, with geographic diversity being a consideration. Employees responsible for managing the service all have access to needed resources to take action from home or the office. An on-call rotation allows for sustained support should issues arise and ensures that resources are available should individuals fall ill.

While Microsoft puts the safety and well-being of its employees at the forefront, their “defence-in-depth” approach is expected to allow for uninterrupted service operation should the virus spread significantly.

Microsoft will make updates on the Message Centre should the situation change.

Posted in Uncategorized | Comments Off on Nexus365 and Covid-19 Coronavirus