RE: and other impatient Postfix mailers everyw here

From: []
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.