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

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

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

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

554 5.4.14 Hop count exceeded - possible mail loop ATTR1

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.

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

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.

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

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.

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.

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

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.

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.