On Sat, 9 May 1998, David W. Tamkin wrote:
Does that mean that the system mailqueue can fill up because
[1] mail for the user who requeues keeps coming back into the queue, and
after several days of requeuing, one user's accumulated mail can fill
the queue; or
[2] when a message is requeued, it still takes up its original place in
the queue because it hasn't been delivered, plus it takes up an addi-
tional slot for its requeued position, and one message requeued enough
times can fill the queue by itself?
#1 is the case. It just goes right back in the queue, and will stay there
until the message times out (which is a system-configurable time, usually
in the neighborhood of 5 days to two weeks).
Smail ignores the exit status of a command to which mail is fed by a pipe in
the aliases file or in a .forward. As long as Smail can fork sh to read the
pipe, Smail considers the message delivered.
You have got to be kidding me. If this is actually the case, then smail is
simply unusable in an email environment where message delivery is
considered important. If you can't fail successfully in any way, then you
can't ever trust an external program to deliver a message. Any kind of
system interference (disk full, out of memory, quota exceeded, etc) could
cause a problem like that.
I have difficulty believing that the authors would not have addressed
this, at least in a later version. Is this perhaps an artifact of a
mis-installation at your ISP?
If it's not, make sure your ISP is aware of this very fundamental problem
with the email subsystem. Point them to QMail, at http://www.qmail.org/
for a leaner, more secure version, which doesn't suffer from any of these
problems, and doesn't suffer from Sendmail's bloat. (I'd suggest VMailer,
but it's not released yet. ;-)
--
-------------------. emarshal at logic.net .---------------------------------
Edward S. Marshall `-----------------------' http://www.logic.net/~emarshal/
Spammers: Please email my blacklisting service at
"spam(_at_)logic(_dot_)net".