Description of problem:
Some sysadmins set the "greet_pause" feature (which waits a bit of time prior to
initial 220 welcome message-- used to foil dumb spambots/zombies that dump spam
to the port without negotiation) in sendmail 8.13.1

If the greet_pause is set high enough, sendmail will reject email alerts coming
from this domain.

How reproducible:
Always.

Steps to Reproduce:
1. set FEATURE(`greet_pause','28000')dnl in sendmail.mc
  
Actual results:
get error message in /var/log/maillog:

Dec 20 11:22:26 havill sendmail[2672]: iBKGMGmM002672: rejecting commands from
alertmail.redhat.com [209.132.177.32] due to pre-greeting traffic
Dec 20 11:22:55 havill sendmail[2675]: iBKGMQt1002675:
from=<dev-null@rhn.redhat.com>, size=4835, class=0, nrcpts=1,
msgid=<200412201622.iBKGMFM07015@alertmail.util.phx.redhat.com>, proto=ESMTP,
daemon=MTA, relay=bltn.redhat.com [209.132.177.31]


Expected results:
the mass-mailer /should/ (not an RFC *MUST*, but an RFC *should*) properly wait
for the 220 greeting.

Additional info:

RFC 2821 states:

4.5.3.2 Timeouts

   An SMTP client MUST provide a timeout mechanism.  It MUST use per-
   command timeouts rather than somehow trying to time the entire mail
   transaction.  Timeouts SHOULD be easily reconfigurable, preferably
   without recompiling the SMTP code.  To implement this, a timer is set
   for each SMTP command and for each buffer of the data transfer.  The
   latter means that the overall timeout is inherently proportional to
   the size of the message.

   Based on extensive experience with busy mail-relay hosts, the minimum
   per-command timeout values SHOULD be as follows:

   Initial 220 Message: 5 minutes
      An SMTP client process needs to distinguish between a failed TCP
      connection and a delay in receiving the initial 220 greeting
      message.  Many SMTP servers accept a TCP connection but delay
      delivery of the 220 message until their system load permits more
      mail to be processed.