procmail
[Top] [All Lists]

Re: Strange problem encountered...

1997-09-22 09:09:29
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

<Prev in Thread] Current Thread [Next in Thread>