> Ok.. so as someone pointed out I have to now search by the deliver
> number.. So I ran:
>
> [root@mail send]# grep "delivery 366" * | /usr/local/bin/tai64nlocal
> 2001-08-09 13:41:28.533103500.s:@400000003b72c36a2839ff1c starting
> delivery 366: msg 112603 to remote [EMAIL PROTECTED]
> [root@mail send]#
>
> Ok.. so the last attempt started at 1:41PM..
> So what happened to the one before it?
>
> [root@mail send]# grep "delivery 26:" * | /usr/local/bin/tai64nlocal
> 2001-08-09 10:17:31.319774500.s:@400000003b72a32e0b08b30c starting
> delivery 26: msg 112603 to remote [EMAIL PROTECTED]
> 2001-08-09 13:41:28.533103500.s:@400000003b72c33a3620be2c delivery 26:
> deferral: qmail-remote_crashed./
> [root@mail send]#
>
> Ok.. so qmail-remote crashed.. but why?
Unless something very unusual is happening to your system, I'd say
that someone or something killed it. An unpatched qmail-remote has no
record of crashing in the last, oh, 3 years of people using it.
> It had also been running for over 3 hours?
That's not necessarily a problem. Mail is allowed to get stuck. Is any
mail getting thru to these sites or are they all failing?
> Well to test it out I did the following:
>
> [root@mail qmail]# telnet mx09.mindspring.com 25
> Trying 207.69.200.36...
> Connected to mx09.mindspring.com.
> Escape character is '^]'.
> 220 pickering.mail.mindspring.net EL_3_4_0 /EL_3_4_0 ESMTP Earthlink
> Mail Service Thu, 9 Aug 2001 16:20:40 -0400 (EDT)
> helo mail.highspd.net
> 250 pickering.mail.mindspring.net Hello mail.highspd.net
> [208.62.90.230], please to meet you
> mail from: [EMAIL PROTECTED]
> 250 [EMAIL PROTECTED] Sender ok
> rcpt to: [EMAIL PROTECTED]
> 250 <[EMAIL PROTECTED]>... Recipient ok
> data
> 354 Enter mail, end with "." on a line by itself
> this is a test.
> please disregard
> .
> 250 tn5s62.1dc.37kbi14 Message accepted for delivery
> quit
> 221 pickering.mail.mindspring.net closing connection
> Connection closed by foreign host.
>
> Ok.. so I can send mail directly just fine.. So what in the heck is
> going on here? This is what is puzzling me the most..?
Hard to say. It could be that the contents of the mail are a problem
for mindspring, are they large? Do they have binary data?
It could be that qmail-remote is connecting to an MX that's
particularly slow or dead.
It could be that you have an smtproutes entry for that domain that
points incorrectly.
> BTW.. this was happening with "stock" qmail also before I patched it
> with the qmail-queue patch for qmailscanner.
If you are saying you are sure that qmail-remote was crashing with a
stock qmail install, then I'd be highly suspicious of a
library/compiler/OS problem. I know that might sound like a cop-out,
but a crashing qmail-remote is virtually unheard of. It's also
possible that there is some sort of system resource that is becoming
unavailable causing the kernel to kill the qmail-remote.
Does this happen to all qmail-remotes or only those sending to
mindspring? Does it happen to all qmail-remotes or only those that run
for a long time?
If you can reliably determine which ones are going to crash in advance
of them crashing, then do a system call trace on one of them to see
why it's dying. Show us the trace.
Regards.
