Deferred: Bad file descriptor after remote side closes connection

I'm having a problem with sendmail where, when running the queue, the
remote side issues a 421 error code and then closes the connection.
Sendmail then fails to deliver any other messages to the same MX with a
"Deferred: Bad file descriptor" error.

>From my maillog:

Mar 8 17:40:22 backup-mx1 sendmail[5363]: j27Kr5Gw004596:
to=, delay=1+01:47:17, xdelay=00:00:06, mailer=esmtp,
pri=4172478, relay=mx5.mail.yahoo.co.kr. [202.43.207.69], dsn=4.0.0,
stat=Deferred: 421 mta106.mail.krn.yahoo.com Resources temporarily
unavailable. Please try again later [#4.16.3:-80].
Mar 8 17:42:53 backup-mx1 sendmail[7052]: j28LSuKV005087:
to=, delay=01:13:57, xdelay=00:00:00, mailer=esmtp,
pri=305472, relay=mx5.mail.yahoo.co.kr., dsn=4.0.0, stat=Deferred: Bad
file descriptor

Running any of the "Bad file descriptor" delayed messages by hand (with
sendmail -qI) works fine, and the messages go through.

At first glance, sendmail appears to continue to try talking to the
same fd that it used previously, but since the remote side had closed
already, it gets the bad file descriptor error.

How can one work around this?

-jeaton

Re: Deferred: Bad file descriptor after remote side closes connection

In article <1110322965.037535.225900@f14g2000cwb.googlegroups.com>
jeaton@gmail.com writes:
>I'm having a problem with sendmail where, when running the queue, the
>remote side issues a 421 error code and then closes the connection.
>Sendmail then fails to deliver any other messages to the same MX with a
>"Deferred: Bad file descriptor" error.

You don't say which version you're running, but maybe this is relevant?
From the 8.13.3 RELEASE_NOTES:

Make sure a connection is not reused after it has been closed
due to a 421 error. Problem found by Allan E Johannesen
of Worcester Polytechnic Institute.

--Per Hedeland
per@hedeland.org

Re: Deferred: Bad file descriptor after remote side closes connection

I was using 8.12.10 and 8.13.1. I upgraded to 8.13.3, and the problem
remains. I'll look at the diffs between 8.13.3 and 8.13.2 and see if
I can figure out why that fix isn't fixing it for me.

Re: Deferred: Bad file descriptor after remote side closes connection

Now that I look over the RELEASE_NOTES, I'm more confused.

8.13.2 says:
If a server returns a 421 reply to the RSET command between
message deliveries, do not attempt to deliver any more
messages on that connection. This prevents bogus "Bad
file number" recipient status. Problem noted by
Allan E Johannesen of Worcester Polytechnic Institute.

This sounds like the actual fix to the problem I'm seeing, although the
wording of the status is slightly different than what I'm seeing.
However, the code which appears to do this (at likes 2903-2913 in
deliver.c) disappeared between 8.13.2 and 8.13.3. Possibly, because of
this, from the 8.13.3 release notes: (?)

Regression: a change in 8.13.2 caused sendmail not to try the
next MX host (or FallbackMXhost if configured) when, at
connection open, the current server returns a 4xy or 5xy
SMTP reply code. Problem noted by Mark Tranchant.

In any case, the problem definately happens with both 8.13.1 and
8.13.3. I'll keep digging.

Re: Deferred: Bad file descriptor after remote side closes connection

In article <1110395644.424884.241820@o13g2000cwo.googlegroups.com>
jeaton@gmail.com writes:
>Now that I look over the RELEASE_NOTES, I'm more confused.
>
>8.13.2 says:
> If a server returns a 421 reply to the RSET command between
> message deliveries, do not attempt to deliver any more
> messages on that connection. This prevents bogus "Bad
> file number" recipient status. Problem noted by
> Allan E Johannesen of Worcester Polytechnic Institute.
>
>This sounds like the actual fix to the problem I'm seeing, although the
>wording of the status is slightly different than what I'm seeing.

That text doesn't come from sendmail but from your OS' C library,
corresponding to the EBADF errno value, so it may differ slightly
between Unix flavours. "Bad file descriptor" is certainly the more
common one, I think.

>However, the code which appears to do this (at likes 2903-2913 in
>deliver.c) disappeared between 8.13.2 and 8.13.3. Possibly, because of
>this, from the 8.13.3 release notes: (?)
>
> Regression: a change in 8.13.2 caused sendmail not to try the
> next MX host (or FallbackMXhost if configured) when, at
> connection open, the current server returns a 4xy or 5xy
> SMTP reply code. Problem noted by Mark Tranchant.

Right - it seems similar code appeared in usersmtp.c (around line 2560)
instead, but I can't immediately see how it covers the "421 after RSET"
case. Then again, I don't know if you've established that this is what
you're seeing - perhaps you can crank up the LogLevel to see the full
SMTP dialogue? I believe 15 does this.

--Per Hedeland
per@hedeland.org