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=<user@foo.com>, 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=<user@foo.com>, 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=<user@foo.com>, 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 (<SLDFKJSDLFKJSDLFKJLKDSJLKFJDSLFKJSDLKFJSD@BOX.senderdomain.com> 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?
Best Answer
You can read with more detail in section 29.9.99 of the 4th edition of the bat book. The bottom line is that most of the time messages that fail to get delivered often, continue to fail.
So when a message is placed in queue, sendmail calculates its priority based on RecipentFactor and ClassFactor and processes those with lowest priority first. Failed attempts get adjusted using RetryFactor and so on.
Also in your case, a 452 tells the machine to defer delivery until later. How much later depends on the value next to -q when you start sendmail .