If you aren't getting your email today (Jan 1), this Microsoft Bug may be why

[Frank Cox]

For anyone whose email goes through Microsoft Exchange, if you aren't getting any email today this is probably why.

https://www.bleepingcomputer.com/new...mail-delivery/

Microsoft Exchange on-premise servers cannot deliver email starting on January 1st, 2022, due to a "Year 2022" bug in the FIP-FS anti-malware scanning engine.

Starting with Exchange Server 2013, Microsoft enabled the FIP-FS anti-spam and anti-malware scanning engine by default to protect users from malicious email.
Microsoft Exchange Y2K22 bug


According to numerous reports from Microsoft Exchange admins worldwide, a bug in the FIP-FS engine is blocking email delivery with on-premise servers starting at midnight on January 1st, 2022.

Security researcher and Exchange admin Joseph Roosen said that this is caused by Microsoft using a signed int32 variable to store the value of a date, which has a maximum value of 2,147,483,647.

However, dates in 2022 have a minimum value of 2,201,010,001 or larger, which is greater than the maximum value that can be stored in the signed int32 variable, causing the scanning engine to fail and not release mail for delivery.

According to additional research on this issue, this is happening because Microsoft is using a signed int32 for the date and the new date value of 2,201,010,001 is over the max value of "long" int32 being 2,147,483,647. @MSFTExchange - Not sure why it was structured this way??

— Joseph Roosen (@JRoosen) January 1, 2022

When this bug is triggered, an 1106 error will appear in the Exchange Server's Event Log stating, "The FIP-FS Scan Process failed initialization. Error: 0x8004005. Error Details: Unspecified Error" or "Error Code: 0x80004005. Error Description: Can't convert "2201010001" to long."

Dear @msexchangeteam. The FIP-FS “Microsoft” Scan Engine Failed to Load. Can’t Convert “2201010001” to long.

— long wtf = 2201010001; (@miketheitguy) January 1, 2022

Microsoft will need to release an Exchange Server update that uses a larger variable to hold the date to officially fix this bug.

However, for on-premise Exchange Servers currently affected, admins have found that you can disable the FIP-FS scanning engine to allow email to start delivering again.

To disable the FIP-FS scanning engine, you can execute the following PowerShell commands on the Exchange Server:

Set-MalwareFilteringServer -Identity -BypassFiltering $true Restart-Service MSExchangeTransport
After the MSExchangeTransport service is restarted, mail will start being delivered again.

Unfortunately, with this unofficial fix, delivered mail will no longer be scanned by Microsoft's scanning engine, leading to more malicious emails and spam getting through to users.

Microsoft has confirmed that they are working on a fix and hope to have more information available later today.

We are aware of and working on an issue causing messages to be stuck in transport queues on Exchange Server 2016 and Exchange Server 2019. The problem relates to a date check failure with the change of the new year and it not a failure of the AV engine itself. This is not an issue with malware scanning or the malware engine, and it is not a security-related issue. The version checking performed against the signature file is causing the malware engine to crash, resulting in messages being stuck in transport queues.

We are actively working on resolving this issue and expect to release details on how to resolve this issue later today. In the meantime, if your organization performs malware scanning of messages outside of your on-premises Exchange servers (for example, by routing mail through Exchange Online, or by using a third-party message hygiene solution), you can bypass or disable malware scanning on your Exchange servers and clear your transport queues. You should use one of these workarounds only if you have an existing malware scanner for email other than the engine in Exchange Server.

[Jim Cassedy]

Apparently Microsoft sent out an e-mail about this, but......

[Frank Cox]

I saw another article saying that this bug was reported to them in 2016 but I guess it wasn't a priority to fix at that point.

I'm unsure if the proper word for this is a bug. It's the result of an inept and negligent design decision (using an inappropriate variable type) so there's really nothing unexpected or surprising about the behaviour.

[Van Dalton]

I'm unsure if the proper word for this is a bug. It's the result of an inept and negligent design decision

"Business as usual".

[Harold Hallikainen]

In 1995, I had to fix some code that would have a logging problem in the year 2000 and beyond (transitioning from 1999 to 1900 instead of 2000). Since the clock chip only had a 2 digit year, the fix was anything less than 95 was in century 20. That will work until 2095.

Then there is the year 2038 problem ( https://en.wikipedia.org/wiki/Year_2038_problem ). About 10 years ago, when we were working on ST 430-10, the auxiliary content synchronization protocol (closed captions), we decided to make the time stamp in the announce request 64 bits instead of 32 bits. That is happening in all the recent standards stuff I've seen.

The most recent update to the QSC LSS-200 and IRC-28C still use a 32 bit time stamp in the log, but the javascript that displays the log considers it to be unsigned instead of signed, so they are good until the year 2106.

More recent systems use a signed 64 bit time stamp which wraps around at 20 times the age of the universe. At that time, we'll need another software update...

Harold