trapdoor.merit.edu and other impatient Postfix mailers everywhere

Thu Aug 2 17:22:39 UTC 2001

If you are receiving larger numbers of reports about failing mail
transport from your customers these days, here is why.

Apparently, the nameservers for the blackholes.mail-abuse.org and
dialups.mail-abuse.org zones are overloaded (I get <10% ICMP_echo's
back, and virtually never any DNS answers), causing a more than
60-second connection-established -> 220 Hello banner
answering delay on typical Unix-based Sendmail (and other SMTP)
servers with default DNS resolver timeouts.

This by itself should not pose a problem given that RFC 1123 5.3.2
stipulates a 5-minute timeout for the banner, but it appears that
a SIGNIFICANT number of mailers out there are losing their patience
after only about 60s: the postfix mailer running the outgoing NANOG-L
mail (trapdoor.merit.edu) is one of them (guess how I found out, heh)

Upon closer examination, I find thousands of these mailers, all
suddenly appearing with lots of Null-connections in my sendmail logs:

Aug  2 12:08:49 sonet sendmail[26668]: NOQUEUE: Null connection \
 from postfix at trapdoor.merit.edu [198.108.1.26]

While I am not sure that the non-responsiveness of the mail-abuse.org
DNS servers for their "subscription-only" query zones is intentional
(how do you shed traffic coming from 1000's of sites that you no longer
wish to serve?), I am just amazed at the wide proliferation of
blazingly RFC 1123-violating implementations/configurations of mail
servers around: why for once, do none of these servers get MORE
patient (after deciding for the first time that 2MB for 60s of
their precious server RAM oughta be enough of their resources wasted
for a delivery attempt for a particular mail to a particular host)
with a host that is not answering 'fast enough' for them?

Have people forgotten the robustness principle and no longer
feel responsible in any shape or form ?

(see RFC 1123,  1.2.1) :

         A vendor who develops computer
         communication software for the Internet protocol suite (or any
         other protocol suite!) and then fails to maintain and update
         that software for changing specifications is going to leave a
         trail of unhappy customers.  The Internet is a large
         communication network, and the users are in constant contact
         through it.  Experience has shown that knowledge of
         deficiencies in vendor software propagates quickly through the
         Internet technical community.

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.

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.

And remember: when mail breaks, your phones don't stop ringing.

bye,Kai

--
"Just say No" to Spam                                     Kai Schlichting
New York, Palo Alto, You name it             Sophisticated Technical Peon
Kai's SpamShield <tm> is FREE!                  http://www.SpamShield.org
|                                                                       |
LeasedLines-FrameRelay-IPLs-ISDN-PPP-Cisco-Consulting-VoiceFax-Data-Muxes
WorldWideWebAnything-Intranets-NetAdmin-UnixAdmin-Security-ReallyHardMath