sendmail under inetd?

sendmail under inetd?

Post by Marcello-Gianluc » Sat, 24 Jun 1995 04:00:00



Hi,

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

 
 
 

sendmail under inetd?

Post by User R » Sun, 25 Jun 1995 04:00:00


: Hi,

: 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.

 
 
 

sendmail under inetd?

Post by Christopher Niels » Tue, 27 Jun 1995 04:00:00





>: Hi,

>: 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.

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.

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

 
 
 

sendmail under inetd?

Post by Mark Seid » Tue, 27 Jun 1995 04:00:00






>>: Hi,

>>: 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.

>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...

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).

 
 
 

sendmail under inetd?

Post by Igor Chudov » Tue, 27 Jun 1995 04:00:00


-----BEGIN PGP SIGNED MESSAGE-----


* >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-----

 
 
 

sendmail under inetd?

Post by Peter Curra » Wed, 28 Jun 1995 04:00:00


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?
>--

Could somebody also offer a similar comment on the overheads involved in
the TIS smap approach?  There is quite a lot of stuff going on in there
as smap is started from inetd, the demon smapd is poking around in the
directory and then sparking off sendmail for delivery.

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

Cheers
Peter

 
 
 

sendmail under inetd?

Post by Mark Seid » Wed, 28 Jun 1995 04:00:00




>>>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.
>   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?

i think your list is accurate.

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?

 
 
 

sendmail under inetd?

Post by Mark Hitting » Wed, 28 Jun 1995 04:00:00



>Could somebody also offer a similar comment on the overheads involved in
>the TIS smap approach?  There is quite a lot of stuff going on in there
>as smap is started from inetd, the demon smapd is poking around in the
>directory and then sparking off sendmail for delivery.
>Also, whilst on the subject, are there any risks involved in using
>sendmail as a delivery engine alone?

Smap does not look at the sendmail.cf, aliases, or anything else.  It just
comes up, does its chroot/drop privs thing.  It speaks an SMTP subset for
a little while and leaves a file in a directory.

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.

 
 
 

sendmail under inetd?

Post by Rahul Dhes » Wed, 28 Jun 1995 04:00:00



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.

   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?
--


 
 
 

sendmail under inetd?

Post by Wm. Randolph U Frankl » Wed, 28 Jun 1995 04:00:00



  >    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/

 
 
 

sendmail under inetd?

Post by Glenn George S. Gonzale » Thu, 29 Jun 1995 04:00:00




> : Hi,

> : 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.

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.

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


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

 
 
 

sendmail under inetd?

Post by Eric Allm » Thu, 29 Jun 1995 04:00:00


|> 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

 
 
 

sendmail under inetd?

Post by Michael Richards » Fri, 30 Jun 1995 04:00:00




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.

  Simple solution to the sendmail start up problem: do not start
it up. Spawn something else that puts the message in the queue.

  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


 
 
 

sendmail under inetd?

Post by George Ro » Fri, 30 Jun 1995 04:00:00



> 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.

That may be true for a site's mail hub, but it's less of an issue for leaf
nodes.  We find it useful to restrict inbound SMTP to only localhost on almost
all our machines, with only the main hub accepting connections from anywhere
and a handful of internal standby hubs that accept connections from our own
machines only.
--
Dr George D M Ross, Department of Computer Science, University of Edinburgh
       Kings Buildings, Mayfield Road, Edinburgh, Scotland, EH9 3JZ

 
 
 

sendmail under inetd?

Post by Christopher Samu » Tue, 11 Jul 1995 04:00:00


-----BEGIN PGP SIGNED MESSAGE-----





>   >    SENDMAIL DAEMON                             SENDMAIL VIA INETD

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

> or read sendmail.fc, which is already parsed.

That depends on which version of sendmail you are running. These notes
are from the RELEASE notes of sendmail V8.6,

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+

 
 
 

1. Sendmail and inetd.conf

Have you checked all these rc possibilities?

mta_start_script="/etc/rc.sendmail" # Script to start your chosen MTA,
called by /etc/rc.

# Settings for /etc/rc.sendmail:
sendmail_enable="YES"   # Run the sendmail inbound daemon (YES/NO/NONE).
                         # If NONE, don't start any sendmail processes.

sendmail_flags="-L sm-mta -bd -q30m" # Flags to sendmail (as a server)

sendmail_submit_enable="YES"    # Start a localhost-only MTA for mail
submissionsendmail_submit_flags="-L sm-mta -bd -q30m
-ODaemonPortOptions=Addr=localhost"  # Flags for localhost-only MTA

sendmail_outbound_enable="YES"  # Dequeue stuck mail (YES/NO).

sendmail_outbound_flags="-L sm-queue -q30m" # Flags to sendmail
(outbound only)

sendmail_msp_queue_enable="YES" # Dequeue stuck clientmqueue mail (YES/NO).

sendmail_msp_queue_flags="-L sm-msp-queue -Ac -q30m"
                                 # Flags for sendmail_msp_queue daemon.

2. Lord of the bugs (euphamism for...)

3. Sendmail in inetd?

4. dhcpd.conf

5. Are sendmail & inetd services necessary?

6. XTerminals?????

7. Sendmail and inetd.conf

8. root password AWOL!

9. inetd and sendmail

10. inetd sendmail telnet problem

11. Why does inetd spawn sendmail for FTP login

12. Boot blocks when it reaches inetd cron sendmail line

13. Q inetd/sockets: how to run my daemon from inetd???