Daniel Suen <ttdsuen(_at_)ln(_dot_)edu(_dot_)hk> writes:
...
Thanks for your suggestion. I don't think we are running LDA versions of
sendmail. As a matter of fact, I compiled and installed Sendmail 8.8.6 on
"LDA version of sendmail"? I think you misinterpreted my use of the
acronym for Local Delivery Agent as a reference to IDA sendmail. I
only use the acronym because it bugs me to type out the entire Local...
an HP-UX 10.10 machine. As to the "sendmail.cf" file, I followed the
Sendmail package instruction to create it, and it runs fine. As to the
local delivery agent, the default is to use "rmail", but as it does not
seem to return right error code, Eric Allman has made up a wrap up code
for me to that tries to return the right error code when unable to
deliver the mail due to quota problem. However, that does not seem to
work. I think I may have to use procmail as local delivery agent. But,
It rmail isn't returning the correct error codes, then that is almost
certainly the source of your problems. When you removed your .forward
file, sendmail went back to using rmail to deliver your mail. If rmail
failed to do so without returning an error to sendmail so that it
[sendmail] would know, then you would lose mail. My guess is that
rmail expects your mailbox to be permissions 660, group mail, and thus
its choking. If rmail doesn't return good codes, then it is BROKEN,
and has FAILED to live up to its contract as a Local Delivery Agent,
resulting in lost mail. Software that does that should killed, and its
head should be left on the pillow of the person who wrote it. Installing
procmail sounds like a no-brainer here.
going back to the problem, I still do not see a clue. I had tried stopping
Sendmail and restarting it again, it does not solve my problem. I also
watched the time stamp /dev/null was last accessed(well, I hope the time
stamp is the one that I should be looking at), the mail does not seem to
go there either.
/dev/null isn't involved here. rmail doesn't need /dev/null to lose
mail; it can just fail to write it successfully anywhere.
Philip Guenther