Bug 143418 - alertmail.redhat.com not compatible with sendmail 8.13.x greet_pause
Summary: alertmail.redhat.com not compatible with sendmail 8.13.x greet_pause
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Network
Classification: Retired
Component: RHN/Other
Version: RHN Stable
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Chris MacLeod
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-12-20 16:54 UTC by Toshiyuki Takamiya
Modified: 2015-06-02 01:18 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-10-17 18:06:29 UTC
Embargoed:


Attachments (Terms of Use)

Description Eido Inoue 2004-12-20 16:54:39 UTC
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.com>, size=4835, class=0, nrcpts=1,
msgid=<200412201622.iBKGMFM07015.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 18:06:29 UTC
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.