- Shing-Gene Yung <[EMAIL PROTECTED]>:
| > Use the -c option to tcpserver to limit the number of incoming
| > connections.
|
| only snag is: I don't use tcpserver...or at least I can't. I tried
| tcpserver at one time but it turned out that it would reject mail
| forwarded from an MS exchange server. I don't remember the exact
| error but once I switched back to inetd it was ok. I'll try and dig
| up that error msg again...maybe you guys can tell me what's wrong :)
Please do. I can't think of any explanation for this bizarre
behaviour. But given appropriate details, maybe it will be possible
to figure it out. In fact, tcpserver is now the only recommended way
to run qmail-smtpd anyway, since there are too many problems that
inetd doesn't handle gracefully.
| Ok, so if the sending qmail receives an OK from the recipient qmail
| it will delete the message from its (sending) queue. If a message is
| in the process of sending but the recipient smptd crashes, then the
| sending qmail-remote times-out and keeps the msg in the queue to be
| re-tried again later. Is that right?
Yes.
| If I see seemingly complete msgs on the recipient queue, and knowing
| that local deliveries are working properly, does this mean the msg
| really isn't complete yet and smtpd hasn't sent out an OK yet?
Not necessarily. You also need to define "complete" carefully.
Quoting the INTERNALS file:
Here are all possible states for a message. + means a file exists; -
means it does not exist; ? means it may or may not exist.
S1. -mess -intd -todo -info -local -remote -bounce
S2. +mess -intd -todo -info -local -remote -bounce
S3. +mess +intd -todo -info -local -remote -bounce
S4. +mess ?intd +todo ?info ?local ?remote -bounce (queued)
S5. +mess -intd -todo +info ?local ?remote ?bounce (preprocessed)
If the message hasn't reached S4 yet, then you're probably right.
Once the message is in S4, qmail-queue will signal success to
qmail-smtpd, which sends the OK. The move from S4 to S5 happens
whenever qmail-send gets around to it, which is normally right away.
| So, if I trash the queue on the recipient side, after shutting down
| smptd connections, I shouldn't lose any msgs, right? (assuming that
| the sending side is ok.)
Well, even local deliveries take a little time (and more if the
machine is heavily loaded). Further, messages may be stuck in the
queue because the user went over quota, turned their sticky bit on,
run a program from their .qmail that crashes or exits 111 or just
plain takes a long time, and enough of the latter may even fill up the
local delivery slots (defined in control/concurrencylocal, or 10 if
you haven't got that file).
But, in the absense of such problems as mentioned above, the queue
usually drains of local messages plenty quick, so I'll say you're not
very likely to have lost any.
- Harald
