Martin Ouwehand writes...
>Aaron Nabil <[EMAIL PROTECTED]> writes:
>
>] >Has anybody seen this: from time to time, a whole bunch of qmail-queue's
>] >will accumulate (I'd say up to ~400), apparently doing nothing (ps shows
>] >that most of them have the same WCHAN, but not all of them). Most of
>] >them have 1 as PPID, a few still have qmail-smtpd as parent.
>]
>] Are they all in TIME_WAIT? It's probably one machine.
>
>It sure is. As to the TIME_WAIT, this doesn't seem to be a problem
>(a "netstat -an" doesn't show to many sockets, in whatever state).
On mine the connections would hang around 2*MSL, but this doesn't
seem to be a problem in your implementation, or you've tuned your
MSL down, sometimes people do that.
>
>] Look in the logs (or use netstat or lsof) to get the IP address of the
>] machine.
>]
>] Use my recordio patch to record dialog just for that host.
>
>Thanks, it was very useful.
You are welcome.
>
>] I bet you'll find qmail is dropping the connection with the "bare LF"
>] message. I've previously given my point of view on qmail's non-RFC
>] compliance on the list before, find that message, apply the patch.
>
>You're right about the "bare LF" message. About your patch: if you mean
>the one where you just comment out those "if (ch == '\n') straynewline();"
>lines, I'm afraid that the exchange following your proposal convinced me
>that this isn't the right solution.
Yikes! I stopped the dialog on the qmail list beacuse it's simply wasn't
productive, not beacause I didn't have more to say. The author's position
on the subject seems political, not technical, and the qmail list is the
wrong place for a politcal debate.
RFC-822 allows bare line feeds. RFC-821 prohibits termination before
quit. RFC 1652 requires 8BITMIME to supress local conversions and
pass data unmodified (although RFC's dealing with the MIME _body_ may
disallow bare LF's, RFC 1652 defines how the MTA must handle an 8BITMIME
envelope). There is no debate on these issues. It's all in black
and white, and qmail violates all three.
That some _draft_ version of a future RFC (that may or may not ever become
an internet "standard") disallows bare LFs is a very flimsy excuse for a
MTA to refuse to interoperate with a MTA that _is_ following RFC-822
_as published_. I fully intended to make sure the the working group
understands that people are using the _draft_ as an excuse not to
interoperate with RFC-822 MTA's, and that some language needs to be
inserted about interoperability. It's perfectly OK for a 822bis MTA
to not generate bare LF's itself (in fact, it shouldn't), but there
are always going to be RFC-822 MTA's out there, and you need to
interoperate with them.
I _am_ going to take it up with the 822bis working group, but plowing
through the existing 5000 messages is taking a while, and there has been
some substantial discussion on the subject before. It may be a couple
weeks.
>BUT, I'm also convinced that the present situation isn't satisfactory. It is
>of no comfort to me that the client is the culprit by not following some RFC
>if my server is on its knees ! So what can we do to avoid this ? One way
>would be not to _exit() in straynewline() but taking care of the state
>we're in is barely within the limit of my window of understanding of the
>source code. What do you think of this ?:
Well, I guess I've already made my opinion about bare LF's known, but
if your intention is still to disallow them but fix the "terminate
before quit" problem, it seems like a reasonable approach. I'm not
sure using a 451 error is desirable, unless your back-up MX handler
is sendmail it's just going to re-queue and fail again. Might as well
use 551 and be done with it.
> . . .
>Another solution for me would be to understand (and fix) why all these
>qmail-queue stay around when their father _exit()'s. For example,
>shouldn't straynewline() do some clean-up before _exit()'ing ?
>
>Thanks for any advice...
I'm just guessing, but there might be some kind of deadlock or
subobtimal signal handling going on with the child. Failing anything
else, I'd imagine the qmail-queue would get a SIGPIPE when the
qmail-smtpd dies, but purhaps it's getting masked, and you are getting
zombification. Dunno, would have to look into it.
--
Aaron Nabil
