Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 143418

Summary: alertmail.redhat.com not compatible with sendmail 8.13.x greet_pause
Product: Red Hat Network Reporter: Toshiyuki Takamiya <takamiya>
Component: RHN/OtherAssignee: Chris MacLeod <cmacleod>
Status: CLOSED WONTFIX QA Contact: Red Hat Satellite QA List <satellite-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: RHN StableCC: nobody, rhn-bugs
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-17 14:06:29 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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:
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.
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