In their infinite wisdom, Microsoft have enabled the Clipchamp service plan – by default – for academic licences prior to the necessary back-end functionality being in-place to provide that service. Until this is resolved it should be expected that Clipchamp will not be available to actually use for Nexus365 users.
The rollout is currently scheduled to complete by the end of September so, at the time of writing, October 2024 is when one can expect it to be available. We might see it sooner…

An IT admin at Tyne Coast College raised a support call with Microsoft to clarify the situation and received the following:

Thank you for your quick revert. As of now that is the expected behavior because Clipchamp is still getting rolled out as I mentioned in my initial email. I would not recommend trying every other day as it will not work and great user dissatisfaction.

 As of now only SKU is getting enabled and the product access is still not being enabled, hence the error which is appearing is expected one. Deadline to complete the Clipchamp rollout for all M365 A3 and A5 tenants is Sep,24. So, start of Oct, 24 is when you will be able to use Clipchamp as expected when the rollout is completed.

If you are bulk-sending to Gmail you need to be fully aware of their sender guidelines. Be aware that non-compliance with these rules will now result in messages being sent to spam folders, at best, or rejected, at worst. There are no exemptions and failure to comply could impact delivery for other parts of the University: our reputation as a sender is predicated on email we send not being marked as spam by the recipient.

For a short period Gmail will send a message back detailing why a message was rejected. It is paramount that you take action immediately to address that issue: failure to do so could hinder ongoing delivery.

The temporary failure messages include error codes that indicate which sender requirement is causing the failure:

Last October Google announced that they would be tightening up their standards for what is acceptable in terms of large quantities of email from a single sending domain. Yahoo! made a similar announcement at the same time.

The first key point to be aware of is that Google and Yahoo have chosen to publicly announce that they’re tightening up their email acceptance  criteria. Not every organisation will necessarily be issuing a press release announcing that fact – bulk-email/spam can be such an annoyance to everybody. So we can be confident that other organisations will be making similar decisions, depending on their perceived scale of the problem, at a time that suits them. We have limited tools available to us to ensure consistent and reliable delivery to our recipients’ inboxes, other than following industry best-practice (which is all they’re asking us to do). It is entirely possible for one part of the University bulk-sending email carelessly to cause the rest of the collegiate University to have their outgoing email sent to spam folders, or rejected entirely. In theory only of course: we’re all far too professional for that to happen, right?

It is therefore vital that all IT Support Staff, in all parts of Oxford, consider and account for these requirements, particularly where they are using any kind of private or third-party bulk sending method. The Email Security Project is endeavouring to apply settings on behalf of the widest possible scenarios and situations but we know that edge-cases exist that may fall outside our visibility, scope, and remit.

Yahoo’s published requirements for bulk-senders

They have not specified a threshold above which these restrictions will apply. Email which fails these checks/requirements will either go to the recipients’ spam folders, or be rejected entirely. In that event a non-delivery report will be sent back to the sender. Spoofed email WILL count against their threshold.

• Email must be authenticated with SPF and DKIM.
• Your domain must have a published DMARC policy.
• ‘From’ headers in outgoing email must be aligned with either the values set in your SPF record, your DKIM record, or both.
• You must include a functional ‘list-unsubscribe’ header supporting one-click unsubscribing (RFC 8058 is recommended).
• A visible unsubscribe  link must be visible in the email’s body text (which can direct to a mailing preferences page).
• Unsubscribe requests must be honoured within 48 hours.
• Spam complaint rates must be below 0.3% (based on Google’s Complaint Feedback Loop service where users mark undesirable inbox content as spam).

Google’s published requirements for bulk-senders

 This is not an exhaustive list and Google’s other standard anti-spam recommended actions still apply.

• A threshold of 5000 emails per day. In our case this will be totalled across all ox.ac.uk subdomains which send outbound email.
• Email must be authenticated with SPF and DKIM.
• Your DNS must contain PTR records for sending domains.
• Your domain must have a published DMARC policy.
• You must include a functional ‘list-unsubscribe’ header supporting one-click unsubscribing (RFC 8058 is recommended).
• Unsubscribe requests must be honoured within 48 hours.
• Senders must remain under a ‘spam rate threshold’ (0.1% in Postmaster Tools) to ensure delivery to Gmail recipients.
• TLS connections must be used for transmitting email.
• Messages must be IME-formatted (RFC 5322).
• Don’t hide HTML or CSS content within your emails.
• Message From headers should only include one email address.

The Email Security Project has already comprehensively tested DKIM and DMARC (with basic SPF records already extant), both in a test environment, and for one subdomain.
The intention is to enable full DKIM and DMARC protection for the entire collegiate University in the next few days, well in advance of Google and Yahoo’s 1st February deadline.

Every migration is different, so the best method will differ too.  But the use of standard protocols, and Microsoft’s vested interest in getting more people onto their platform, mean that migrating into  Nexus365 is usually straightforward, reliable, and simple.

Third-party migration tools also exist, which may be able to bring across more than just messages, but those would need to be managed by the ITSS in charge of the source data.  It should also be noted that some parts of the University have simply self-migrated by configuring Outlook to open both mailboxes side-by-side: users can drag-and-drop content from one to the other.

There are a few considerations to bear in mind whatever migration method will be used:

• Email routing and the timing of changes will need to be considered carefully – if the old mailbox is removed prior to the routing being updated, new incoming email could disappear into a black hole. To ensure this doesn’t happen the timing of routing changes, and user communication, is crucial.
• Users may need support in reconfiguring email clients on the day of any routing changes. We strongly advise ITSS to show users how to access Nexus365 webmail (‘OWA’) ahead of time, since that will give mailbox access from any web browser without the need for special reconfiguration.
• There may be forwarding configured on the Nexus365 mailbox to redirect email to the previous departmental system: those forwards will need to be removed on a carefully-managed schedule to avoid creating mail loops.
• Depending on exactly when in the migration process a user connects to Nexus365, they may find their mailbox empty: their old content is ‘backfilled’ into the new mailbox. Setting user expectations for this saves many support issues! Where migration delays would be unacceptable a user could self-import content via a PST file, or equivalent, rather than wait for the migration to finish.
• Existing content, such as calendar appointments, may lose the ‘friendly name’ of the person arranging the meeting once the old server is disconnected (the old address book won’t be available for lookups). We usually advise people to try to generate new items rather than attempt to edit historical ones, in an effort to minimise this effect.
• Users should be made aware that not all content can be migrated (a non-exhaustive list could include: rules, out-of-office messages, tasks, notes, signatures, auto-complete addresses, etc.) A migration from another Microsoft Exchange version will be the most complete.
• Nexus365 mailboxes are sized by the assigned licence, either 50GB or 100GB. Mailboxes in excess of the available space will either need to be assigned an A3 licence (users only; not shared mailboxes) or they will need to request an archive mailbox in which to store the excess content. The archive will usually have an assigned policy moving the oldest content into the archive automatically.
• Users with shared mailboxes will need to document and reconfigure any permissions which allow someone else access to their mailbox’s content. All shared mailboxes on Nexus365 must have a clearly-defined owner responsible for its content.
• Distribution groups and delegated group management will need to be considered and, perhaps, updated to use a different technology, such as a Sympa Mail-List, or a Microsoft Team.
• Resource mailboxes, such as parking spaces or meeting rooms will need to be re-created. Historical meetings migrated into a meeting room’s mailbox may lose their association with their original owner.
• Teams Rooms devices will need to be updated to use a new account, via a service request, which also requires a cost-code to which the associated licence’s purchase cost can be assigned.
• Migration capacity – the migration process creates a lot of simultaneous connections and can overwhelm modest hardware. You should ensure that the migration is timed or batched in such a way that your source server isn’t DDOS’d by the migration process itself.

To improve delivery of our outgoing email DKIM and DMARC were enabled for the it.ox.ac.uk domain on Thursday 16th November, as a proof-of-concept that these technologies are beneficial and don’t create new message delivery issues. Generally it’s SPF records that are the ones that cause issues, since a list of authorised servers is always going to flag up any unofficial ones that might be present…

Naturally for the first few days I’m keeping a close eye on message reporting and identifying anything which can be fine-tuned or improved. Here’s how the first three days with active DKIM and DMARC have gone so far. The University’s weekend email traffic is always significantly down on weekday usage, so there’s only one full working day with useful data to analyse so far:

• Fully trusted
  SPF and DKIM are both successful; DMARC checks pass.
• Partially trusted
  Either the SPF or the DKIM check succeeds; DMARC checks pass. These messages will still be delivered for all three DMARC policy settings. This is also the group to concentrate on to strengthen SPF or DKIM.

  The next three categories all comprise DMARC failures, because SPF and DKIM checks have both failed. The exact outcome will depend upon your selected DMARC policy. In all three cases these will help identify if the failures relate to a system under your domain’s remit which requires reconfiguration, or if it is due to email being spoofed. Or both…

• Untrusted
• Quarantined – These emails are sent to the spam folder.
• Rejected – These emails are not delivered to the user.

Initial observations

There were 254 messages flagged as ‘untrusted’, which is 17.6% of the total sent.

158 of those were from the LISTSERV mailing list platform.
100% of messages failed DMARC from the LISTSERV platform, likely because the current DMARC policy is ‘none’. Jiscmail’s handler automatically detects a DMARC policy of ‘reject’ or ‘quarantine’ and ensures successful delivery.

28 of those were untrusted but were still successfully delivered due to ARC being able to assert that DKIM was valid up to the last intermediate provider in the email delivery chain.

The proposed plan is therefore, as a next step, to move to a DMARC policy of ‘quarantine’ but with a percentage value of zero (pct=0). This has an effective outcome identical to the ‘none’ policy, but LISTSERV will cease spoofing our domain.

Sorry about that.

We are currently in a ‘grace period’ where Microsoft allows Teams Rooms devices without a valid device-specific licence to still continue to work. This represents an extension of 90 days from the original deadline, which was going to be 1st July 2023.

We can see that there are a number of unofficial Teams Rooms devices in use within the University, mostly operating via a normal user’s login. Doing that is a potential breach of University regulations, as well as a potential breach of licencing terms. I therefore urge you to legitimise these devices via the official service request process as soon as possible, and ideally well before the end of September 2023: this is when the current grace period ends and represents the point at which these devices will cease to work.

The Nexus Team will not be operating any special expedited process to register devices which have been operating outside the rules which are caught out by this long-advertised and significantly-postponed change in licencing rules.

Approximately 7 days from today, Microsoft are going to permanently turn off basic authentication in the Nexus365 tenancy.
You should only be affected if you have already received a notification from IT Services, which was sent to all identifiable people who were using Basic Authentication in early December 2022.

In September 2019 Microsoft first announced that Basic Authentication was too insecure to be allowed as an ongoing method of authentication. After numerous announcements and updates over the following three years, we are now at the stage where Microsoft are now turning off basic authentication for all their customers worldwide, for the following protocols: MAPI, RPC, Offline Address Book, Exchange Web Services, POP, IMAP, Exchange ActiveSync and Remote PowerShell. The University requested a delay, which was granted, but which has now reached its end.  Today Microsoft selected our tenancy, and in approximately 7 days, they will disable basic authentication for all Exchange Online protocols except SMTP.

How this may affect you
Any clients or applications still using basic authentication with the affected protocols will be unable to connect to Exchange Online.
Note: They are not changing any settings for SMTP AUTH or turning off SMTP AUTH.
Any client (user app, script, integration, etc.) using basic auth for an affected protocol will be unable to connect to Exchange Online. The client will receive an HTTP 401 error: bad username or password. Any app using modern auth for these protocols will be unaffected.

To read more on what can be done to switch apps from basic to modern auth please view our main documentation page and our latest blog.

What can I do if I need more time?
There are no options to re-enable basic auth for these protocols: they will have been permanently disabled. We have already requested an extension, which is now expiring.

If you have ever sent an email only to realise – after sending – that there’s a reason why you shouldn’t have sent it, Microsoft have some good-ish news for you. Message Recall is being updated.

Historically the ‘recall message’ option has only really drawn attention to the problem message, as recipients are prompted to decide if they will permit the message to be recalled unread. Natural curiosity means most click ‘no’ and then search their way through the message for the juicy gossip you’ve sent by mistake.

From November Microsoft are modifying how recall operates. Instead of the historical client-based approach, which is dependent on Outlook being used as the email client, the new behaviour will be for the recall to be processed directly in the cloud, at users’ mailboxes. When an email client synchronises with the cloud, the message can be removed.

This is still not quite the panacea that you might be hoping for, if you’ve ever needed to recall a message however. If the message was read by the recipient already, it can still be recalled but they’ll still have seen the recalled content. Clients can also be configured to reject recall requests.

The unique set-up we have in Oxford also changes things – in most organisations there’s just one email system, but Oxford has some departments running their own service, forwarding content elsewhere, or running a separate Microsoft tenancy. In those situations a message recall has more potential to fail.

Perhaps the most useful feature of this change is that you’ll be able to see an aggregated report of the status/progress of your attempt to recall a message: for whom it succeeded, and for whom it failed.

Message Recall process

Roadmap article about message recall: https://www.microsoft.com/en-us/microsoft-365/roadmap?rtc=1&filters=In%20development&searchterms=59438

Demo of the message recall process, from MEC: https://youtu.be/2rj44zp-Oe8?t=2284

For the steps to follow I can recommend this guide from Practice Protect and this one from Microsoft.
There is some confusion about the way that these commands are implemented, with inconsistent behaviour noted, so it’s sensible to follow all of the advice even when it seems redundant.

Example: The documentation says to run these commands:

Get-AuthenticationPolicy

(to find the name of the existing authentication policy).

Replace <AuthenticationPolicyName> with the value from the previous step, and then run the following command:

Set-AuthenticationPolicy -Identity "<AuthenticationPolicyName>" -AllowBasicAuthReportingWebServices:$false -AllowBasicAuthOutlookService:$false

The previous command affects new mailboxes that you’ll create, but not existing mailboxes. To apply the policy to existing mailboxes, use the <AuthenticationPolicyName> value…

Testing reveals that on an IMAP connection to a mailbox this setting sometimes blocks existing accounts and sometimes it doesn’t.  Other Universities’ IT Staff have reported a similar outcome: testing with Thunderbird occasionally permitting mailbox access after multiple connection attempts. In other words these settings variably affect existing accounts, contrary to the guidance.

The sensible solution seems to be to disregard any odd outcomes you may observe during testing and simply follow the published guidance as if no anomalous behaviour was noted: set a DefaultAuthenticationPolicy at the organisation level and set an AuthenticationPolicy on every user.

Thanks to SysAdmins at UEA and University of Dundee for their observations on the Jiscmail mailing list which contributed to this post.