Under what conditions will sendmail try to immediately resend a message instead of waiting for the standard requeue interval?
Posted
by
Mike B
on Server Fault
See other posts from Server Fault
or by Mike B
Published on 2012-12-07T19:35:23Z
Indexed on
2014/06/08
3:28 UTC
Read the original article
Hit count: 271
CentOS 5.8 | Sendmail 8.14.4
I used to think that if SendMail experienced a temporary (400-class) error during delivery, it would place the message in a deferred queue (e.g. /var/spool/mqueue) and retry an hour later. For the most part, that appears to be the case. But every now and then, I'll notice log entries like this (email/domains renamed to protect the innocent :-) ) :
Dec 5 01:43:03 foobox-out sendmail [11078]: qBE3l7js123022: to=<[email protected]>, delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=124588, relay=exbox.foo.com. [10.10.10.10], dsn=4.0.0, stat=Deferred: 421 4.3.2 The maximum number of concurrent connections has exceeded a limit, closing transmission channel
Dec 5 01:53:34 foobox-out sendmail [12763]: qBE3l7js123022: to=<[email protected]>, delay=00:10:31, xdelay=00:00:00, mailer=relay, pri=214588, relay=exbox.foo.com., dsn=4.0.0, stat=Deferred: 452 4.3.1 Insufficient system resources
Dec 5 02:53:35 foobox-out sendmail [23255]: qBE3l7js123022: to=<[email protected]>, delay=01:10:32, xdelay=00:00:01, mailer=relay, pri=304588, relay=exbox.foo.com. [10.10.10.10], dsn=2.0.0, stat=Sent (<[email protected]> Queued mail for delivery)
Why did Sendmail try again just 10 minutes after the first attempt and then wait another hour before trying again?
If this is expected behavior, what scenarios will cause this faster requeue interval to occur?
© Server Fault or respective owner
