Spammers illustrating, well, something
I'm on the general mailing list for Exim and over time I've become used to seeing what I'll call 'please do my homework' requests there. By this I don't quite mean literally requests for this (so far no one seems to assign configuring Exim as homework for some class), but instead requests for help with problems which clearly show that the requester has not attempted to help themselves and is turning to the mailing list as a last resort; instead the mailing list is serving as a first or second resort. This is probably completely normal for any open source software with a decent usage level and I've long since gotten over being particularly irritated about it.
Every so often, though, the mailing list sees an unusually spectacular instance. Such as this recent one:
Working with sending e-mail marketing and I'm using cpanel / whm with exim in its latest version.
Need to optimize the shipping of exim, and to receive e-mail the same now send direct to the recipient, and that was not generating the send queue.
I have noticed that the server is sending queue accumulating and analyzing the logs shipping seems that ISPs are blocking recipients immediate receipt, claiming the high flow of sending e-mail, noting that 100 IPS rotacioando have every referral, this set RDNS, SPF and DKIM,
I suppose I shouldn't be too surprised. (Self-admitted) e-mail marketers need to send their email using something and sometimes they're going to use the same mailer that I do. And some of them are going to ask other people to do their homework without entirely thinking the whole thing through.
(This message was met with a resounding complete silence on the Exim mailing list, which restored a bit of my faith in humanity.)
Universities and long term perspectives
I expect that in many places my habit of looking five or ten years into the future for things I'm considering would be seen as more than a little bit daft and pointless. In a company the problems you have in five or ten years are likely to look much different than what you have today; if a system has survived at all, it's quite likely to have grown or otherwise changed drastically as the business scaled up or mutated (this is especially true in startups and other small companies that are trying hard to grow).
This is not the case at universities. It is a rare department that changes so much in even ten years as to require its existing IT systems to change dramatically. Departments just generally don't get drastically larger or smaller or different; the fundamental things that they do haven't changed for a long time (and are unlikely to change in the future) and changes in scale tend to be quite slow. A department doubling in size is considered really drastic growth.
(Universities also naturally have a significant amount of stability in who is there. Professors generally have tenure and so stay for decades while graduate students frequently take half a decade or more from when they start to when they get their PhD and leave. Even the undergraduates are generally here for four or five years.)
The result is that software and large scale systems can routinely live for a long time, and in fact the long term people like this long term stability in the environment around them. Of course in an ideal environment you'll turn over the physical hardware reasonably frequently, but your overall design can stay the same because the work it needs to do is the same and scope and scale haven't changed drastically. Real shifts in technology or in the demand for services are relatively infrequent (at least in my experience).
(Of course you don't have to keep systems going for five or ten years, but change for the sake of change and nothing more is generally not a good thing. In some ways this is a luxury and in some ways this is a burden.)