sendmail 8.12.8

[The Alliance]

Hi,

I have built and installed the subject software on our test system. Everything works great with the very important exception - local mail cannot be delivered. I keep recieving the errors in mail.log

---
Mar 25 14:38:57 dev1 sendmail[24717]: h2PKcvAe024717: from=root, size=131, class=0, nrcpts=1, msgid=<200303252038.h2PKcvAe024717@dev1.rss.hyatt.com>, relay=root@localhost
Mar 25 14:38:57 dev1 sendmail[24718]: h2PKcv2i024718: from=, size=429, class=0, nrcpts=1, msgid=<200303252038.h2PKcvAe024717@dev1.rss.hyatt.com>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
Mar 25 14:38:57 dev1 sendmail[24717]: h2PKcvAe024717: to=ops, ctladdr=root (0/3), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30116, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (h2PKcv2i024718 Message accepted for delivery)
Mar 25 14:38:57 dev1 sendmail[24720]: h2PKcv2i024718: forward /home/ops/.forward.dev1+: World writable directory
Mar 25 14:38:57 dev1 sendmail[24720]: h2PKcv2i024718: forward /home/ops/.forward+: World writable directory
Mar 25 14:38:57 dev1 sendmail[24720]: h2PKcv2i024718: forward /home/ops/.forward.dev1: World writable directory
Mar 25 14:38:57 dev1 sendmail[24720]: h2PKcv2i024718: forward /home/ops/.forward: World writable directory
----

Then after some time the following error is displayed.

---
Mar 25 14:40:57 dev1 sendmail[24720]: h2PKcv2i024718: timeout waiting for input from local during Draining Input
---
Mar 25 14:42:16 dev1 sendmail[24720]: h2PKcv2i024718: to=, ctladdr= (0/3), delay=00:03:19, xdelay=00:03:19, mailer=local, pri=30631, dsn=4.0.0, stat=Deferred: local mailer (/usr/bin/rmail) exited with EX_TEMPFAIL
---

The mail never gets delivered. Can anyone provide any insigts as what I can check to verify local delivery. FYI, I am using the local mailers provided with HP.

Any help will be greatly appreciated.

DParkin

[Ross Zubritski]

Verify all of your permissions using the install guide at www.sendmail.org.

Regards,

RZ

[Steven E. Protter]

This looks like totally a permissions problem.

Look here

forward /home/ops/.forward: World writable directory

Thats a security problem. If that file is world writable user schmo can change the .forward file and steal all of ops's mail.

Is that a good thing? Nope.



I'm enclosing a good email reject diagnostic command line. No extra charge. Just run it to a real email address, type a line of text, hit enter, a period(dot .) hit enter again. You'll get good diagnostics.

/usr/sbin/sendmail -v -d8.99 -38.99 somebody@your.net

SEP

[Kasper Haitsma]

Hi

>..forward /home/ops/.forward.dev1+: World writable directory
As per the previous respondants, you should check the permissions, but i would 1st try without these and aliases. Move them out of the way.

>timeout waiting for input from local during Draining Input
From KNOWNBUGS
* Delivery to programs that generate too much output may cause problems. If e-mail is delivered to a program which generates too much output, then sendmail may issue an error:

timeout waiting for input from local during Draining Input

Make sure that the program does not generate output beyond a status message (corresponding to the exit status). This may require a wrapper around the actual program to redirect output to /dev/null.
...
From Per Hedelund on groups.google.com:
...
If sendmail is talking to a typical local mailer program that expects the message on stdin, and that program produces a lot of output on stdout/err, it might be the case that sendmail doesn't get around to reading that output, and so the program blocks in a write when the pipe is full and stops reading its stdin, and then sendmail blocks on writing *that* pipe - i.e. deadlock. This certainly doesn't happen in traditional versions, as the program's stdout/err is simply directed to the "transcript file" (xf*), but I seem to recall there was some problem with the fancy buffering etc in recent versions...

By redirecting *the mailer program's stdout/err* to /dev/null, you would avoid this - but also lose the output that may be important in error situations, i.e. it's only useful for debuggging. Also it can't provoke the problem, only take it away.
...
Since you use the standard hp-ux mailers, 'something' causes this mailer (local:/usr/bin/rmail) to complain to much to sendmail, causing the timeout.
Does the reference in sendmail.cf, match the actual presence of the binary (sounds obvious, but just checking)? On my machine (hp-ux 11.00), it is linked to /bin/mail with props: -r-sr-sr-x root:mail.


> ..stat=Deferred: local mailer (/usr/bin/rmail) exited with EX_TEMPFAIL

stat=deferred, means it is queued for future delivery (in /var/spool/mqueue by default, you would find a qfh2PKcv2i024718 and dfh2PKcv2i024718 and maybe xfh2PKcv2i024718 files)

EX_TEMPFAIL indicates a temporay failure of the delivery agent (rmail in this case). The mailer expects this to be (possibly) resolved at a future attempt. This CAN be one of many causes (unable to create lock file, file system full [due to the excess amount of output])

If I were you, I would 1st attempt without aliasing and forwarding (Keep [make] It Simple), and with the sendmail.cf that worked, before the 'upgrade'. Next, I would follow up on every complaint (in sequence) made by sendmail.

HTH
Kasper

[The Alliance]

Just to let everyone know, the permissions are setup according to sendmail.org and the directories that are showing up as world writable do not exist. I'll try some of the suggested recommedations and let you know.

[Steven E. Protter]

Maybe the users in the error messages are referred to in aliases file or other config files. This could trigger the error.

Or maybe NIS issues?

SEP

[The Alliance]

E-mail cannot be delivered to any user locally. I however can send e-mail anywhere in the world and e-mail and be relayed through the system to anywhere in the world. Not sure if this info would provide more info. There are only 4 users on this system. I could get around the problem by aliasing MAILER-DAEMON, postmaster and root to another system but that does not fix the real issue. If you notice from the logs I sent the local mailer actually accepted the message, then it complains about directories (which do not exist) being world writeable. Maybe as most are suggesting it is a permissions problem, am just not able to figure what. I have ensured all my files and directories match what sendmail.org suggest. I'll go through again to see if I missed something.