2020-10-11
Microsoft SharePoint is being used to send spam
I'm paying more attention to what our mail system detects as spam and where it's coming from than usual, so I'm getting to notice things (or, in the alternate phrasing, being forced to notice things). Today's thing that I noticed is that to no one's surprise, Microsoft SharePoint is currently being used as a spam sending vector. I say 'to no one's surprise' because it's a long standing rule that anything that can be used to send email to random people with any user supplied content will be exploited for spam (eg).
The email we see is genuine SharePoint email sent from Microsoft, DKIM signed by both sharepointonline.com and 'spoapaceop.onmicrosoft.com', with the envelope address of no-reply@sharepointonline.com and sent to us by outlook.com machines. Typical headers look like:
From: Katholina Keth <no-reply@sharepointonline.com>
Subject: Katholina Keth shared "❤Unsatisfied women Need a guy ❤" with you.
The header samples I've seen have a long list of To: addresses at all sorts of places (not just our university subdomain or even the university as a whole). Some messages have a Reply-To: pointing to various addresses at a legitimate domain, which may be a signal that the spammer has compromised a part of that organization so that they can either hijack accounts there or register their own, then use them to register in SharePoint.
(I only have access to some message headers, so I can't tell what is in the body of the email. Hopefully Microsoft doesn't allow SharePoint emails to include substantial amounts of user-supplied content, so all people get is a link to where the spam is.)
At one level all of this is unsurprising. As a product feature, it's attractive to let SharePoint users share their files and other SharePoint materials with people who haven't already signed up with SharePoint, and when you do that of course SharePoint has to tell the target something about what is being shared. The title is an obvious thing to include, and you have to let users change the title of their documents. But now Microsoft has given spammers the ability to send some amount of relatively arbitrary text to relatively arbitrary email addresses.
(I would like to say 'and now Microsoft has a problem', but of course they don't. Very few people are in a position where they can block SharePoint email over this.)
Our current usage and views of UPSes (late 2020 edition)
Over the time I've been here, we've had rather mixed experiences with UPSes. Initially we used them relatively freely on machines that we felt were important, such as our first generation ZFS fileservers. Unfortunately, after a while the UPSes themselves caused us problems (for example, a spontaneous UPS reset that power cycled the machine attached to it), and we grew much more disenchanted with them.
These days we still use UPSes on some machines, such as our fileservers, but pretty much only on machines with redundant power supplies and good IPMIs. One power supply goes to the UPS and the other power supply to line power (via a rack PDU), and we've done as much as possible to make it so that if one power supply sees a power failure, we'll get notified about it. Most of our servers have only one power supply, so we don't even consider putting them on a UPS (even with an automatic transfer switch, of which we have some from days past).
(We don't currently try to monitor or talk to our currently in use UPSes, but we should at least look into that. Probably they're capable of it, since they're decent quality rack mounted units.)
Today, this is the only configuration that I feel comfortable with for production use, because it doesn't add any new single points of failure but will probably give us protection from power loss (assuming the UPS is working properly; if it's not, we're no worse off if we lose main power).
We've historically not bought many servers with redundant power supplies, but that's starting to change now that we're working remotely and fixing a server with a dead PSU is much slower and more work. This may push us toward more use of UPSes, although that's not as useful as it looks because our network switches generally only have one power supply and so won't be on a UPS.
(The other issue with putting switches on a UPS is that right now it would cut off our ability to power cycle them remotely, since they generally don't have a full equivalent of an IPMI to enable internal remote power control. There are various hacks possible here, though.)
Some UPSes stop working if their batteries are unhealthy or dead, which is not something we want to have happen with our UPSes. There are multiple ways to implement a UPS, called topologies, that you can find described in eg Wikipedia, but I don't know if any of them actually require this or if your UPS stopping if the battery is dead is just a choice that UPS vendors make. Our current practice is to replace UPS batteries on a reasonably regular basis, partly to avoid any unpleasant surprises like this.
(Once we're actually talking to our UPSes, hopefully they will tell us about this sort of thing.)