04-04-2013 12:43 AM
I just need to send mails from my hpux box 11iv2.
Sendmail-Upgrade B.11.23.1.007 Sendmail-8.13.3/Identd special release upgrade
I do not want to receive mails.
We have smtp relay server.
We have an entry in DS sendmail.cf
I read in form that we dont need sendmail daemon running to send mails .
But when i stop sendmail daemon am not able to send mails from my hpux box.
Bleow is entry we are finding in syslog maillog ;
Apr 4 13:00:32 abc123 sendmail: r347UW9Y005685: to=fnsonlgs, ctladdr=root (0/3), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=31882, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Solved! Go to Solution.
04-04-2013 03:13 AM
Hi i went through the below forum ;
It has put a doubt in my mind .
04-09-2013 01:01 AM
Before Sendmail version 8.13, it was possible to disable the sendmail daemon and still have the outgoing mails work - sort of.
Why "sort of"? Because it only worked fine if everything was OK. If there was a network problem or the destination mail server was unable to receive mail, those mails would be stuck in the outgoing mail queue (/var/spool/mqueue) forever. The sysadmin could fix it (running "sendmail -q" would have made another attempt to deliver the messages in the outgoing mail queue, or generated bounce messages if the original outgoing mail was too old), but there was no warning or log message telling the sysadmin about this.
As a workaround, it was common to schedule a cron job to run "sendmail -q" e.g. once in every hour if the sendmail daemon was disabled.
Sendmail version 8.13 included a rather significant architecture change in Sendmail: before it, Sendmail used to be a setuid root program that could immediately deliver local mail to any user's local inbox (/var/mail/<username>) as soon as the mail was submitted. But that made Sendmail rather vulnerable for security exploits, so in 8.13, two distinct roles were created: a queue processor and a mail submission handler. Both roles would run the same sendmail binary (to ensure legacy compatibility), but the binary would no longer need to be setuid root: the sendmail processes would only have root privileges if started by the root user.
The sendmail process started at boot time by the /sbin/init.d/sendmail script would be the queue processor. It is started by root, so it would have root privileges as before. It needs root privileges so that it can check for ~/.forward files in each user's home directory, write to each user's local inbox, and start listening for connections in TCP ports 25 and/or 587.
When a user, program or a script runs the "sendmail" command of version 8.13 or later, the sendmail command runs as an unprivileged mail submission handler. To actually send the message, the mail submission handler must get it to the queue processor somehow, as the connection to other mail servers might require SSL/TLS certificates and keys, which should be accessible only for the queue processor running as root. To send the message to a local user, the message must be written to the destination user's /var/mail/<username> file, which also requires more privileges than the mail submission handler has.
This is why Sendmail 8.13 or newer in HP-UX always requires a sendmail daemon to be running: if the mail submission handler cannot contact the queue processor at 127.0.0.1, the mail cannot be sent.
However, it is still possible to configure Sendmail daemon version 8.13 or newer to not listen on any external network interfaces. This would block the receiving of mail from other hosts, but would still allow host-internal mail and outgoing messages to work.
In HP-UX 11.31, there is a variable SENDMAIL_SENDONLY in /etc/rc.config.d/mailservs file. Setting it to 1 and restarting sendmail would do exactly what you need. Perhaps the Sendmail-Upgrade B.11.23.1.007 includes the same functionality?
After installing the Sendmail-Upgrade, you may need to copy the updated template mailservs file from /usr/newconfig/etc/rc.config.d/mailservs to /etc/rc.config.d/mailservs first to see the new variables.
You may also have to generate a special "send only" sendmail.cf file using the /usr/newconfig/etc/mail/cf/cf/gen_cf script.
Please see the HP-UX Mailing Services Administrator's Guide:
You should read at least pages 43-44, 54 and 59 for the send-only functionality.
And as always, if you configure any host to only send but not receive emails, you should contact the administrator of your SMTP relay server and have him/her configure the relay server to do something sensible to any bounce messages that might be created as a result of mails sent from the send-only box. The bounce messages are very useful when troubleshooting mail delivery problems; you should at least have some plan for catching them at the relay server if you need to troubleshoot a mail delivery problem, even if you normally discard them.