Sendmail Issue

[Ankitj_1]

Dear Techies,

Yesterday i faced an issue on sendmail.

I stopped all sendmail daemaons to stop sending mails.

After some time i received complaint from the user that thery are still can send emails.

Then i comment lines starting with Dj & DS in sendmail.cf file afterwards thre problem rectified.

Can anyone tell me without daemon how mails were getting delivered.

REgards

Ankit

[Matti_Kurkela]

This "issue" is a fundamental consequence of how sendmail traditionally works in unix-style systems.

Sendmail is not only a daemon; it can also be started in non-daemon mode to send an email message immediately. This "one-shot mode" is used by many traditional Unix programs that can send mail, e.g. mailx and crond. Users can even write scripts to use this mode directly.

When sendmail is started in "one-shot mode", it reads the sendmail.cf and makes one attempt to deliver the mail according to the configuration. If DS (or equivalent) is not set, sendmail will use DNS records (types MX and A) to find the destination mail server and attempt to deliver the message directly to the destination server.
(If the sending host is in a NATted network, this direct delivery attempt will usually fail, because messages sent from hosts with no public IP address and a matching DNS name will be discarded by junk email filters at the destination server.)

If DS is set, sendmail will deliver the message to the configured "smarthost", which will usually be your organization's main mail server, for further processing.

Up to this point, the sendmail process running as a daemon is not involved at all.

If the one-shot delivery attempt fails, the one-shot sendmail process will simply store the message in /var/spool/mqueue.

If the system has sendmail running in daemon mode, the daemon will notice the new queued message and will make a series of further delivery attempts at configured intervals.

But if there is no sendmail daemon running, any queued messages will remain in the queue forever. If the queue is not cleared by the sysadmin, the accumulation of queued emails may eventually cause the /var filesystem to fill up to 100%.

Simply stopping the sendmail daemon is not enough to prevent users from sending mail out of a Unix system. Even preventing the users from executing /usr/sbin/sendmail (or historically /usr/lib/sendmail) is not a complete solution: users who know how SMTP works can send basic emails by connecting to port TCP/25 of any accessible mail server using a telnet client and then typing SMTP protocol messages manually: as the SMTP protocol is human-readable, it's easy. Even the telnet client is not necessary: a short Perl script that requires no special privileges can do the same job.

The only effective way to block outgoing emails from a host is to use firewalls or IPFilter to block all outgoing connections from that host to ports TCP/25 (SMTP) and TCP/465 (SMTP over SSL).

If you want to block only some emails, you must allow connections to your organization's mail server only, then configure that server to accept/reject messages using whatever criteria is applicable.

MK

[Anshumali]

Whole theory is above but to make it simpler for your solution:

You can try changing the execute permission on sendmail and mailx:

# ls -ltr /usr/sbin/sendmail
-r-sr-sr-t 1 root mail 2561608 Jun 19 2007 /usr/sbin/sendmail
# ls -ltr /usr/bin/mailx
-r-xr-xr-x 1 bin bin 465596 Nov 30 2006 /usr/bin/mailx
# chmod 444 /usr/bin/mailx
Now:

# mailx
sh: mailx: Execute permission denied.

As said above, sendmail can be used to send a one shot mail using sendmail/mailx and the a decent way to stop is having firewall b/w your server and relay server. Obscure ways are change permission as above or make sure mailhost resolves to unknown address. Mailhost to unknown server will fill up your mqueue as deferred messages and permission will just stop anyone using those 2 commands.