Summary of the bug: Exchange tried to store "2201010001" (i.e. date time '22-01-01 00:00) in a 32-bit signed int, but INT_MAX is 2147483647 so the result is a negative number.
I wouldn't call one bug, in one software a "vengeance". Yea, it's widly used, and affected lots of mail but was very limited and had a trivial work-around.
But, the Y2K issue, back then, was in 1000s of software from 1000s of vendors. The only Y2K affect I remember was the first issue of 2600 in 2000.
I love the solution: They changed their antimalware definition files to December 33rd, 2021, until they have a more substantial patch ready. The instructions are just to basically clear out the existing files and re-download to get rid of that pesky 2022 year.
This bug was extensively discussed yesterday:
Microsoft Exchange stops passing mail due to bug on 1/1/22 (677 points / 355 comments)
Submitters: please don't editorialize titles. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html. We've reverted the title now. (Submitted title was "Y2K problem came back with vengeance in 2022".)
It's surprising how often this issue (ceiling for 32-bit ints) comes up way.
If you're still using integers (for ids, timestamps, etc) then just go with 64-bits. It avoids any potential problem with data size in the future, and if the size stays small then it won't matter anyway. Storage is cheap and CPU cache lines are 64-bit now too.
Can you imagine being a dev on this bugfix? The bug is known, but every second wasted testing, regressing, and preparing to deploy, literally millions of emails aren't delivered. That's some serious pressure.
I wonder if there were detectable drops in internet traffic due to fewer emails?
Wow, what a bug.
The malware scanning service of MS Exchange crashes, because it treats a yyMMddHHmm timestamp as a signed integer when verifying a signature file.
Turns out that 2201010001 is negative when treated as a 32 bit integer (the greatest positive one is 2147483647, and 2021 had fewer than 47 months).
I can only assume that somebody wrote that "timestamp string as integer" code, checked that it worked correctly (at the time) and then just assumed they must be good on data type range.
I'm rather surprised the test suite for a product like Exchange wouldn't include setting date types to ($TODAY..$FAR_FUTURE).
Site has this confusing update:
> Addendum: A fix ist available.
Are we speaking German now? Or is that a typo for isn’t? Or is, maybe?
Long ago I learned a lesson: Don't write your own date time handling code.
(because you will always miss something)
Any reason they didn't make the int unsigned from the get go? Or would that also cause issues?
Please, D. Knuth just solve this dates for computers problem once and for all!
[dead]
So many spelling mistakes!
Maybe this will kill the last remenants of people thinking they are using spf when they are actually using senderid
I'm pleased the error message actually mentioned exactly what's wrong.
Compare the two snippets in [1]:
> Description: The FIP-FS "Microsoft" Scan Engine failed to load. PID: 23092, Error Code: 0x80004005. Error Description: Can't convert "2201010001" to long.
> Description: The FIP-FS Scan Process failed initialization. Error: 0x80004005. Error Details: Unspecified error.
I hope it's trend that continues because when it's going pear shaped every little morsel of information is important to narrow down the problem.
I'm less pleased they seemly didn't deploy this update to an internal on-prem test Exchange server before a wider release.
[1]: https://techcommunity.microsoft.com/t5/exchange-team-blog/em...