Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Disabling sendmail



A simple and easily reversible way of keeping sendmail from being
started is to find the sendmail executable and change the name
to something like 'sendmail.dont' ; the startup scripts on
distros I've tried check for the existence of the sendmail
executable and recover gracefully if it's not there.

On Fri, 18 Feb 2000, John Abreau wrote:

> On Fri, 18 Feb 2000 Vincent Cocco <vcocco at admin.suffolk.edu> wrote:
> 
> > I'm currently running Linux Mandrake and do not want to run sendmail.  I
> > know you can just go into the RedHat setup screen and uncheck the box
> > and not have it run when the system boots.  I've done this, but then
> > when I try sending an email to an account on the Linux box, (as a test)
> > it always get's delivered.  This does'nt make sense to me:  why  disable
> > sendmail on startup only give to people on the outside the ability to
> > send mail to an account on the Linux box?
> > 
> > There's so many init* files, which one do I edit to comment out the
> > startup line for sendmail?
> 
> When you send the test message, are you sending it from the local machine
> or from a remote system? If you're sending it locally, most mail composers
> will start up a private instance of sendmail to hand off delivery to.
> Shutting down the sendmail daemon disables the SMTP port so incoming mail
> won't be accepted, but local mail doesn't go through the SMTP port.
> 
> On the other hand, if mail from a remote system is getting delivered, i.e.
> if the SMTP port is indeed active, then (on Redhat) you can go into
> each of the /etc/rc.d/rc*.d directories and delete the S*sendmail startup
> files. Mandrake used to be based on Redhat, so I'd guess the directory is
> most likely in the same place. Note that the GUI tools for managing the
> runlevels are essentially just deleting or renaming these S* and K* files.
> 
> --
> John Abreau / Executive Director, Boston Linux & Unix 
> Email: jabr at blu.org / URL: http://www.blu.org
> ICQ#28611923 / AIM abreauj
> -----------------------------------------------------------------------
> "Working with NT is like trying to tune a watch wearing oven mitts.
>  You can't get your fingers inside like you can with UNIX.
> -----------------------------------------------------------------------
> 
> 
> -
> Subcription/unsubscription/info requests: send e-mail with
> "subscribe", "unsubscribe", or "info" on the first line of the
> message body to discuss-request at blu.org (Subject line is ignored).
> 

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org