Brain-dead Office 365 mail handling courtesy of Microsoft

[Rich Jordan]

Our work email has been "upgraded" from a local exchange server to the new and sparkly cloud "Office 365" service (after having previously been severely downgraded from Domino and Sendmail to local exchange some years ago). MS apparently decided to go cheap and stupid on their filtering software.

Emails with attachments; if the attachment _name_ ends in .EXE, .MSI, or .COM (and some others) they are globally filtered. Customers have no choice in this. That's maybe fine if you're using mail generated from and destined for windows machines but we have real computers here.

In VMS a command procedure (script, a human readable text file) has file extension .COM (and that has been the case since before Microsoft existed). We have automated procedures that build and email .COM files as attachments to an email which are retrieved (via POP or IMAP) by a local VMS system; these procedures are analyzed, then run (under restricted accounts) to update local info and databases. Worked fine for 15 years, even with local exchange. The MIME type is text/plain.

Now those files are 'filtered out' and replaced by, ironically, another text file that says blocked by filter that doesn't like *.COM and is itself named the same as the attachment except for the extension being renamed .TXT. Apparently the only thing the brain dead filter looks for is the extension; doesn't matter that the file is not (and can't be) an x86 DOS or windows executable. Doesn't matter that the source and destination systems are not x86 DOS/windows. Doesn't matter that the .COM does NOT mean what they think it means. Oh no, you can't have the scary .COM file because Microsoft knows Best!

F*cking microsoft. F*cking corporate nanny state email now. Now we get to update all the procs to either zip or rename the command procedures and undo at the central end. Yeah, it won't be hard, but I should not have to do this just because f*cking windows systems go into paroxysms if an executable shows up in email...

Thank you for the opportunity to rant.

[Rich Jordan]

Brought up that stuff prior to the conversion but we're all 'cloud is the all!' OMG ponies! MS can do no wrong! here right now. We'll see. The last I heard the internal exchange server is staying until a particular voicemail issue is resolved (the phone system integrates with exchange for VM purposes, but does not work with O365).

[308Mike]

Now, WHY would ANY company want to keep mission-critical information available through the Internet??? Just so you could say you're "cloud capable"???

What a bunch of CRAP.

I realize there are SOME companies who would benefit from the "cloud" concept, but just because you're not one of the "BIG-BOYS" who play in the cloud, it doesn't mean you should, or even HAVE TO play in the cloud to accomplish your company's objectives!!!

[mekender]

Oh and if you ANY kind of production, mission critical, security etc... dependencies on your email service; you MUST maintain at least a local mail exchanger for local messages to be relayed through; in case you lose external internet, the cloud goes down, the cloud glitches out, or you have to drop off the net for security or infrastructure issues.

You CAN NOT solely depend on cloud services when you have production or operational critical email, full stop.

And that is why MS is making a private cloud service as part of the offerings so that the "cloud" in question will be locally hosted or at least corporate hosted.