trapdoor.merit.edu and other impatient Postfix mailers everyw here

Thu Aug 2 18:27:27 UTC 2001

> From: kai at pac-rim.net [mailto:kai at 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.