Bug 143418
| Summary: | alertmail.redhat.com not compatible with sendmail 8.13.x greet_pause | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Network | Reporter: | Toshiyuki Takamiya <takamiya> |
| Component: | RHN/Other | Assignee: | Chris MacLeod <cmacleod> |
| Status: | CLOSED WONTFIX | QA Contact: | Red Hat Satellite QA List <satqe-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | RHN Stable | CC: | 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 18:06:29 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 |
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.