Bug 143418 - alertmail.redhat.com not compatible with sendmail 8.13.x greet_pause
alertmail.redhat.com not compatible with sendmail 8.13.x greet_pause
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Other (Show other bugs)
RHN Stable
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris MacLeod
Red Hat Satellite QA List
Depends On:
  Show dependency treegraph
Reported: 2004-12-20 11:54 EST by Toshiyuki Takamiya
Modified: 2015-06-01 21:18 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-17 14:06:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eido Inoue 2004-12-20 11:54:39 EST
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:

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 [] 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 []

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: 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.
Comment 2 Amy Owens 2008-10-17 14:06:29 EDT
This bug has been closed due to inactivity.  Please open a new bug with specific details if this problem is still occurring or if an enhancement is needed

Note You need to log in before you can comment on or make changes to this bug.