i need to shutdown sendmail.... help! 1

[gchen]

i suspect my server got trajon and it became an email replay for unknown party. i wish to shutdown my sendmail and go some investigation. how can i shut it down?

thanks much!

 

[gchen]

i got it!

/etc/rc.d/init.d/sendmail stop

next thing is how would i find out if i got email relay trajon?

any tips is appreciated!!!!!!!!

 

[mrballcb]

You don't say what distro or OS you use, so I'll assume some kind of RedHat variant. Go look in /var/log/maillog or /var/log/mail/info (the Mandriva Linux location). Look to see where mail is coming from and where it says it is sending it to.

First, never enable relaying based on DNS. Some spammer puts your mail server as an MX for his spamming domain and your mail server will happily send out all mail from his domain.

Second, let's say that you own 'gchen.com'. If you put in your sendmail to relay any mail from *@gchen.com, then you have just opened your machine up for spammers. I could say I am 'greg@gchen.com' and send all the mail I want through your machine. Check to make sure that you do not relay by domain, only by IP (set it to allow relaying for your local network).

If your reply is "I need to be able to send mail when I or my boss is doing work in New York" then you need to setup SMTP Authentication. If that's what you need, there's a whole lot of HOWTO's out there for setting that up with sendmail.

Good luck!

 

[gchen]

thanks for the tips, yes it is a redhat box and i would like to relay by ip instead dns. is it one of the parameter in sendmail.cf or something similar?

or can i use linuxconf to make the change?

 

[mrballcb]

If you want to allow relaying by IP, sendmail reads a file named /etc/mail/access. I will assume nothing fancy like an LDAP backend. I'll assume that your local network is behind some kind of masquerading firewall, such as a Linksys. I'll assume that your local network is 192.168.1.0/255.255.255.0.

Edit the file /etc/mail/access. Add to the end of the file on a single line by itself:
Connect:192.168.1 RELAY

If you have other local networks that you want to allow relaying for, you can put them in here as well, one per line.

After you have saved this file, recreate the access.db file but changing into the /etc/mail directory and run (as user root) 'make'. There is a Makefile that RedHat provides that rebuilds the individual *.db files in that directory if it's needed.

When you rebuild the *.db files, you do not need to restart sendmail. You only need to restart sendmail if you edit the /etc/mail/aliases file or create a new sendmail.cf. It reads both of those files once at initial startup, the rest of the *.db files are reread for each incoming email that sendmail processes.

 

[gchen]

i tried to stop sendmial and i ....

/etc/rc.d/init.d/sendmail stop

and i got [ok] echo'ed back

then i went on checking ....

/etc/run/sendmail.pid and it was not there

then i did a top and ...

i still found sendmail in the top list with PRI jumping among 1 to 10

then i did a ps -ef and it reported

sendmail: accepting connections

Is the normal? i thought once i stop sendmail, it should not be seen in top as well as the sendmail.pid will be gone.

another observation is when i use ps, very often i encountered below error message...

Signal 17 caught by ps (procps version 2.0.4).
Please send bug reports to <procps-bugs@redhat.com>

Are these enough indication that this redhat linux box got trajon?

all tips are helpful and most welcomed!!!!

Thanks!

 

[mrballcb]

On occassion, things don't get shut down properly. So, kill all the sendmail processes with:
killall sendmail
If they're still there in a ps ef:
killall -9 sendmail

If they're still there, you have a hung process (weird), which _may_ be indicative of a hacked machine, but I would think not. Crackers go through extremes to cover their tracks and wouldn't leave a hung process like that. In the very least I would assume they would reboot the machine to get rid of it and hope you don't notice it.

I don't like the Signal 17. My first guess is to check the memory with a good memchecker (ie a floppy disk that you boot and it cycles through RAM testing consistency). That could also very easily explain the sendmail process being hung. Check for fans that aren't running either as high heat can cause strange failures in mobos and cpus (the worst kind, erratic failures).

 

[gchen]

I checked /etc/mail/access and i got below ...

localhost.localdomain RELAY
localhost RELAY
127.0.0.1 RELAY
##################################################
spammer@aol.com REJECT
cyberspammer.com REJECT
192.168.212 REJECT
##################################################
# Entries from obsoleted /etc/mail/relay_allow
2 RELAY
# Entries from obsoleted /etc/mail/ip_allow
2 RELAY
# Entries from obsoleted /etc/mail/name_allow
2 RELAY
2 RELAY
...

i think it's cool on the relay setting, ami correct?

if so, i think my problem on mail replay is cleared for which Thank You very much!

but the question about "sendmail: accepting connections" while i have already got an [ok] from "sendmail stop", do you have any clue?

Thanks for all your help!

 

[gchen]

thanks! i will look into my memory and other stuff to make sure ps is functioning fine. i will try out killall and hopefully things getting back to normal after that. Really appreciate your insight and guidance.

Have a good one!

 

[mrballcb]

If 192.168.212.* is your local network, the REJECT line tells it to *NOT* relay mail from those IP's. I would change it to:

Connect:192.168.212 RELAY

but the question about "sendmail: accepting connections" while i have already got an [ok] from "sendmail stop", do you have any clue?

If you happened to do an '/etc/init.d/sendmail start' while it was already running, that could explain it. The sendmail.pid file gets overwritten with the wrong information. Then when the init script tries to shut it down, it dies because the wrong (or no) info is in the sendmail.pid file.

I think you'll find that on occassion a process refuses to die without a little forceful nudging. When you have bad memory or failing hardware, that type of thing happens frequently and can be perceived as Linux being unstable, when in fact it is the hardware that is being flaky. Again, I don't know with certainty this is your problem, but it's a path to try.

 

[gchen]

no, 192.168.212 is the sample ip addresss came with sendmail configuration file just as spammer@aol.com and cyberspammer.com in the sendmail.cf file.