Very Computer

could it be possible to have "sendmail" run under inetd? Maybe this would allow
better access control (e.g. via TCP-Wrapper, xinetd, etc.).

Any ideas?

--
   /| /|+-----+--|\     Dr. Gianluca Faieta & Dr. Marcello Formica
  / |/ ||__   |  | \    CNUCE-CNR  Parallel Processing Lab
 /     ||     |  |__\   Addr:   Via S. Maria, 36, I-56100, Pisa, Italy

: could it be possible to have "sendmail" run under inetd? Maybe this would
: allow better access control (e.g. via TCP-Wrapper, xinetd, etc.).
:
: Any ideas?

Yes, You will find instructions on how to do that in the tcp-wrapper README
file, included below. But you can of course run from inetd without having
the wrapper, if you dare.

        The tcpd program can even be used to control access to the mail
        service.  This can be useful when you suspect that someone is trying
        out some obscure sendmail bug, or when a remote site is misconfigured
        and keeps hammering your mail daemon.

        In that case, sendmail should not be run as a stand-alone network
        listener, but it should be registered in the inetd configuration file.
        For example:

 smtp    stream  tcp     nowait  root    /usr/etc/tcpd /usr/lib/sendmail -bs

        You will still need to run one sendmail background process to handle
        queued-up outgoing mail. A command like:

 /usr/lib/sendmail -q15m

        (no `-bd' flag) should take care of that. You cannot really prevent
        people from posting forged mail this way, because there are many
        unprotected smtp daemons on the network.

-Chris
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Christopher Nielsen                           UCA&L
Systems and Network Administrator             Buffalo, NY

both ways you have to accept the connection and fork off a sendmail
to handle smtp through final delivery.

i see no reason to believe that sendmail5, sendmail8, et al are all
better at doing this than inetd, xinetd, etc.

i'd like to see numbers if anyone has them...

however, to return to the original question:

if the point is "access control" -- controlling what IP addresses are
allowed to send you mail, give up, unless you can control who can send
*them* mail also. Due to the nature of SMTP and the tradition of mail relaying
this is an exercise in futility.

if the point is to accept only safe mail, better to run smap (from the
TIS firewall toolkit) to take your smtp connections on the firewall,
and use sendmail to do the final delivery.  smap is much more paranoid
and lightweight.  (but you still end up using something like sendmail
eventually).

* >It's generally considered a bad idea to run sendmail out of inetd because
* >of the amount of overhead required to start a daemon from inetd. Since
* >sendmail has the ability to handle multiple connections, this can become
* >relatively expensive when your mail connection is being flooded, either
* >unintentionally or otherwise.

* ah, baloney.  show me some numbers to prove it.

* both ways you have to accept the connection and fork off a sendmail
* to handle smtp through final delivery.

* i see no reason to believe that sendmail5, sendmail8, et al are all
* better at doing this than inetd, xinetd, etc.

* i'd like to see numbers if anyone has them...

Some considerations: when sendmail forks, it does not have to read and
parse its huge config files. It is actually a great overhead because if
sendmail is simply listening, all pages of code responsible for config
files are swapped out. The often needed code of sendmail is in memory,
which is very handy when the mail load is high.

- --
        - Igor. (My opinions only)

               http://www.galstar.com/~ichudov/index.html
   For public PGP key, finger me or send email with Subject "send pgp key"

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBL+8utMJFmFyXKPzRAQFTfgP/fB/+HJXCefA7d7Afx2Sobrp77NwSEflT
YqEP/o0ph/rfkK6NxgTNZY4vhhAk/KE64KCuHHYB/JXTWpztZahOVZl/7/eOAxRM
Wox0x74DV/CY6ENOVpZyix8DR85eZVi3mIO673HzovBnLcu7RfQqYP6M2+unxyht
vbjOZhzB0tg=
=3NvI
-----END PGP SIGNATURE-----

Quote:

>>ah, baloney....

>>both ways you have to accept the connection and fork off a sendmail
>>to handle smtp through final delivery.

>   SENDMAIL DAEMON                             SENDMAIL VIA INETD

>   1. fork()                                        1. fork()
>                                            2. exec() sendmail
>                                            3. parse sendmail.cf

>The second column seems more expensive to me, but I do not know by how
>much.  Numbers would indeed be the right way of establishing the
>respective eficiencies.

>When a running sendmail daemon does fork(), does the child inherit and
>reuse descriptors to any needed dbm files, or would this create lseek
>conflicts and does the child have to open afresh any needed dbm files?
>--

Also, whilst on the subject, are there any risks involved in using
sendmail as a delivery engine alone?

Cheers
Peter

add to the list whether sendmail.cf has been frozen (say, pre sendmail
8) or needs to be reparsed, whether /usr/lib/sendmail is cheap to exec
because it's already in some cache or other, dynamic library issues
when doing the exec etc.

i'm really curious how much of a difference it makes.

i'd bet a dollar it's noise compared with the cost of a single DNS
lookup.  (i don't think i'd bet a bottle of champagne, though...)

things brings up a related question...

does anyone have a methodology or framework for doing internet mail
benchmarking?

Another process called 'smapd' comes along and inspects these files for
niceness.  Then smapd forks off a sendmail process to actually deal with
the delivery of the message.

I have not seen any medium or big problems yet.  It looks like a very
resonable way to deal with the entire issue.  The only thing that I do
see is the delivery of a large email to a bad address.  Smap will accept
the entire file and not reject it.  The rejection comes later from the
invocation of sendmail.

Smap and Smapd are tiny programs, so they don't really hammer the pager
very much.  Sendmail still has to do its parse of the .cf ect.

Give it a try.

Regards,

Mark Hittinger

--
"This is going to cause more confusion than a mouse in a burlesque show." -
                                                        Foghorn Leghorn.

Quote:>>It's generally considered a bad idea to run sendmail out of inetd because
>>of the amount of overhead required to start a daemon from inetd....
>ah, baloney....
>both ways you have to accept the connection and fork off a sendmail
>to handle smtp through final delivery.

   1. fork()                                    1. fork()
                                                2. exec() sendmail
                                                3. parse sendmail.cf

The second column seems more expensive to me, but I do not know by how
much.  Numbers would indeed be the right way of establishing the
respective eficiencies.

When a running sendmail daemon does fork(), does the child inherit and
reuse descriptors to any needed dbm files, or would this create lseek
conflicts and does the child have to open afresh any needed dbm files?
--

  >    SENDMAIL DAEMON                             SENDMAIL VIA INETD
  >
  >    1. fork()                                     1. fork()
  >                                          2. exec() sendmail
  >                                          3. parse sendmail.cf
                                                   ^^^^^^^^^^^^^^^^^

or read sendmail.fc, which is already parsed.

------------------------

 ECSE Dept., 6026 JEC, Rensselaer Polytechnic Inst, Troy NY, 12180 USA

            (2) http://www.ecse.rpi.edu/homepages/wrf/

====================================================================
         ___     Glenn George S. Gonzales
  __ _  (__ |    c/o Department of Computer Science
 / _` |  (_ |    University of the Philippines, Diliman, QC
( (_| | (___|    920-5301 to 99 loc. 5200
 \__, |


====================================================================

|> add to the list whether sendmail.cf has been frozen (say, pre sendmail
|> 8) or needs to be reparsed, whether /usr/lib/sendmail is cheap to exec
|> because it's already in some cache or other, dynamic library issues
|> when doing the exec etc.
|>
|> i'm really curious how much of a difference it makes.
|>
|> i'd bet a dollar it's noise compared with the cost of a single DNS
|> lookup.  (i don't think i'd bet a bottle of champagne, though...)

Mark, you owe me a dollar :-).  Sendmail does at least one DNS
lookup on startup (for the local host name), so you are guaranteed
to have a startup cost greater than the cost of one DNS lookup.

eric

Quote:>True, you can do that, but I read somewhere that running sendmail
>from inetd is very costly in terms of overhead.  Sendmail requires
>a considerable amount of time to initialize.  If it were to run from
>inetd, it would do this each and every time a client connects to
>the smtp port of your server.  If you receive a lot of mail, this
>may be a problem for you.

  We called this program "recvmail", and will be releasing it
later this summer, after it has been cleaned up a bit. recvmail
is just smart enough to do ESMTP on fd 0, and drop the message
into the sendmail queue. No calls to system(), no config file
to read, and no root required if /var/spool/mqueue is writable
to the user id you pick.

  The only problem is that it does not have the load limiting
functions that most sendmail's do: but that type of control belongs
in inetd anyway.

--
   :!mcr!:            |     <A HREF="http://www.milkyway.com/">Milkyway Networks Corporation</A>
   Michael Richardson |   Makers of the Black Hole firewall

8.6/8.6         93/10/05
[...]
        Remove support for frozen configuration files.  They caused more
                trouble than it was worth.
[...]
6.30/6.10       93/02/27
        Require FROZENCONFIG compilation flag to include frozen
                configuration code.  Frozen configuration is really
                not a very good idea any more, particularly in shared
                library environments.
[...]

cheers,
Chris

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCVAwUBMAEANFJ7nmUlvnM9AQH6PwP+MrZxdohiJ/OBEpX8pt353QVQiPqJANGC
l3OQOjW76pQQHnwx1saUrbiiLZ7bqGtJ+8/u+SsHAtgZKr4LoKYRMpvOTRHvQ1rp
h8r9jo0/qTddYF6GnK3LFT/SLJ6ROCKl+pdRr0xNX3HSCgfCqbIMkXtDUmK4Q6LA
DMnRiOAkj9I=
=ppO/
-----END PGP SIGNATURE-----
--

 N-115, Defence Research Agency,  St Andrews Road, Great Malvern, England, UK
 DISCLAIMER: I write only for myself, not for DRA.     Phone: +44 1684 894644
 +MIME+                                                                 +PGP+