From: kai@pac-rim.net [mailto:kai@pac-rim.net] Sent: Thursday, August 02, 2001 10:23 AM
Hello Kai, Having many of the dot-coms, that you blast so thouroughly here, as clients ...
E.g.: this is not MAPS' fault. This is large site's (Hello Yahoo!) SMTP MTAs (and excuse me for not having researched the shipped default timeouts for Postfix here, I am not blaming Postfix or any particular SMTP MTA here, as administrators tend to have their hands too deeply in the config files) screwing it up for all of us:
They are mistakenly thinking that, (while violating RFC 1123 that was designed with interoperability and stability in mind, not max. profit margins) defining an arbitrarily small number of resources for their flawed business model does not have consequences beyond their own service.
Read first part "administrators ... hands too deeply ...", then read second part "abitrarily small ...", then realize that most of their bosses don't even know enough to tell them "what" to do, let alone "how". Rather, they trust then to know what they're doing as they give them the goals. As an example; I had one client complain that their office LAN was always short on disk space. They couldn't understand it since they had just installed 250 GB of RAID. It turns out that they had a BOFH over there that was doling out DASD, 100 MB at a time (Quotas), for a 25-man office. The BOFH was running Gnutella and warez on the "unused" space. This is a page right out of the BOFH book. The BOFH is gone, the quota system is disabled, and they hired a Linux kid as SysAdmin. They now have sufficient space. The kid sometimes has to figure things out, but he isn't going on any power-trips anytime soon. ... an adequate trade-off.
MAPS's changing server arrangements just happen to be the coincidential "contributing failure" here, but the true cause is apparently marketing, financial and other blithering idiots at the wheel at Yahoo, Verizon, Flonetwork (and 1000's of other dot-coms) making resource decisions over the heads, and beyond any sane reason, of responsible technical personnel that knows better than them what will fly and what won't, and why.
Often, it is the SysAdmins, not the business folk that make these decisions. Often without the business folk fully realizing what's going on.