Sendmail on RHEL

By default sendmail in RHEL listens only to  localhost  interface:

netstat -tulpn | grep sendmail

tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      8108/sendmail: softpano

As you can see it's only listening to 127.0.0.1 port 25.

That corresponds to the following /etc/mail/sendmail.cf setting:

# SMTP daemon options

O DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA

you can edit /etc/mail/sendmail.cf or /etc/sendmail.cf depend on your operating system.

and edit as

# “Smart” relay host (may be null)
DS<mailserver_hostname>

exam.
DSmailserv.whathappen.com

PS.

if you used dns name, or hostname ,please make sure that your server can lookup ip from hostname.

referrence :

http://blogitknowledge.u-indy.com/syste ... l-quickly/

NEWS CONTENTS

• 20090225 : Sendmail on RHEL 4.0 - Without DNS ( Sendmail on RHEL 4.0 - Without DNS, Feb 25, 2009 )
• 20090225 : Installing Sendmail on RHEL4 - Linux Forums ( Installing Sendmail on RHEL4 - Linux Forums, )
• 20090225 : How to troubleshoot RHEL performance bottlenecks by Ken Milberg ( How to troubleshoot RHEL performance bottlenecks, )

Old News ;-)

How to setup Relay host in sendmail

/etc/mail/relay-domains contains a list of hosts which are allowed to relay mail through your mail server. This list may consist of either specific hosts or whole domains.

/etc/mail/sendmail.cw (after sendmail version 8.10, this file is local-host-names) contains a list of domains for which your mail server will accept mail. This list is usually the domains hosted by your machine.

NOTE: put a CR/LF at the end of the last domain. Otherwise it won't work.

Of course you have to set up your actual sendmail server to use the mail relay.
If your unix host has to use a mail relay to get out, the simplest, usually enough, method is to define the DS (smart relay) macro in sendmail.cf. You should have a line with
DS
change it in
DSmailrelay.domain
where mailrelay.domain is the FQDN of your mail relay as seen from your side.
The stop/start sendmail to let it reread the config file.

This mail relay must accept SMTP connection from your host and must accept relaying. To check if the mail relay is working try

telnet mailrelay.domain 25
.... answer from mail relay .....
helo <unix hostname>
mail from: root@<unix hostname>
rcpt to: <email test>@<something out>
data
mail test from unix
.

mail server should answer something like mail sent. If this work you can try with a normal mail client like

mailx -s "subject" <email test>@<something out>
mail test from unix
.

To check if this has work look at /var/adm/syslog/mail.log
you should see a couple of lines stating the mail has been accepted locally and sent to the relay and accepted.

Good luck.

"It's always a long day, 86,400 won't fit into a short."

[Feb 25, 2009] Sendmail on RHEL 4.0 - Without DNS

March 20, 2007 | www.phase2.net

For any of you who have ever tried to use or configure sendmail, you know it's not a fun task. At best, you wince, try to browse some google groups as you make your way through the billions of posts regarding some tribal knowledge that has to do with this release of sendmail on that specific OS. Then throw DNS into the mix, sendmail's partner in crime and we've got a real ho-down. Especially when DNS goes missing. When DNS doesn't arrive for the party, sendmail gets mad.

Real mad.

Anyways, in alot of our networks, we have hosts that don't have DNS. Why? Because we're too lazy to set the shit up. Seriously tho, it's mostly because work has me stuck on building machines ( ie: monkey work ) rather than trying to solve the real issues in our infrastructure. Since I just spent the last hour trying to figure out how to get a RedHat Enterprise 4 ( U4 ) machine to send mail without DNS to a smart relay host, I thought I'd share the results and how to do it.

First, make sure you have the sendmail-cf package installed. Either install it locally via media or use yum/up2date to get it.

rpm -ivh sendmail-cf-8.13.1-3.RHEL4.5.i386.rpm

Next, add your smart relay host to your /etc/hosts file

192.168.0.6 mailhost mailhost.domain.com

Go into /etc/mail/ and vi the sendmail.mc file. Add the following lines:

FEATURE(`accept_unresolvable_domains')dnl
FEATURE(`accept_unqualified_senders')dnl
FEATURE(nocanonify)
define(`confSERVICE_SWITCH_FILE', `/etc/mail/service.switch')dnl
define(`SMART_HOST',`mailhost')

Note: The first character after the "FEATURE(" is a tick mark ( ` ) from the tilde key, this is not a typo. The ending quotation is a single quote mark ( ' ). I've enclosed the code in pre tags, although it looks ugly, to ease copying and pasting into the configuration. Please look at the sendmail.mc file for more clarification.

Of course, replace the mailhost with the host you entered in your /etc/hosts file. Now create a file in /etc/mail called service.switch and add the following:

hosts files

For our last file modification, edit the submit.mc file in /etc/mail and add the following line:

define(`confDIRECT_SUBMISSION_MODIFIERS', `C')dnl

Now that we're done making our file modifications, simply type 'make' while in the /etc/mail directory. You shouldn't see any output, but if you do a directory listing, you should see some .bak files now. You can compare these with the current .cf files to see what changes were made.

Restart sendmail and the sm-client:

service sendmail restart

And voila! You should now successfully be able to send mail to your smart relay host with no DNS. To test, trying something like this:

mail -s test [email protected] < /dev/null 2>&1 >> /dev/null

Cross your fingers, sacrifice a few goats and chickens, do a little dance, make a little love and check your inbox for the test email.

12 Responses to "Sendmail on RHEL 4.0 - Without DNS"

1. Dad Says:
   March 20th, 2007 at 8:34 pm

   Steve, it sure seems like a lot of work,
   Just use hotmail, it works every time, haha!

2. Jocko Says:
   March 21st, 2007 at 9:08 am

   post the conf!!!

3. beji Says:
   June 7th, 2007 at 4:25 am

   This really works.Thanks pal it is very useful.If anyone tries to copy and paste the configs from this tutorial please take a note that the ' sign is pasted like . and may be thats the problem for the tutorial not working.So if you are useing Putty or other ssh client please be sure that the pasted text is exactly like this one otherwise wont work.Once again thanks man for this great how to.

4. steve Says:
   June 7th, 2007 at 12:29 pm

   Thanks beji. I'm glad you've found it helpful. I've made a note in the document to try and clarify the situation that m4 uses a tick mark and a single quotation.

5. Massimo Says:
   December 4th, 2007 at 5:33 am

   Great tutorial! Now also my sendmail seems to work.
   I applied this guide on an old red hat 9 with sendmail 8.12.8
   Thanks a lot.

6. AT Says:
   December 6th, 2007 at 7:19 pm

   HI,

   Thanks a lot. This really works.

   Regards

7. Aleksey Tsalolikhin Says:
   July 11th, 2008 at 10:25 am

   Very helpful, thanks for posting this! Aleksey.

8. Marco Says:
   July 20th, 2008 at 2:26 am

   Great article, and this is what I was looking for, but I am using CentOS 5 and I get this error:

   [root@localhost mail]# mail -s test [email protected] &1 >> /dev/null

   in /var/log/maillog:

   Jul 20 12:13:24 localhost sendmail[3068]: m6KADO1c003068: from=root, size=35, class=0, nrcpts=1, msgid=, relay=root@localhost
   Jul 20 12:13:24 localhost sendmail[3069]: m6KADONS003069: from=, size=330, class=0, nrcpts=1, msgid=, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
   Jul 20 12:13:24 localhost sendmail[3068]: m6KADO1c003068: [email protected], ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30035, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (m6KADONS003069 Message accepted for delivery)
   Jul 20 12:13:24 localhost sendmail[3071]: m6KADONS003069: to=, ctladdr= (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=120330, relay=mailhost [192.168.1.20], dsn=4.0.0, stat=Deferred: Connection refused by mailhost

   I do a telnet:

   [root@localhost mail]# telnet mailhost 110
   Trying 192.168.1.20…
   Connected to mailhost.domain.com (192.168.1.20).
   Escape character is '^]'.
   +OK Dovecot ready.

   Dovecot is working.

   Any clues about what could be wrong?

9. steve Says:
   July 20th, 2008 at 9:06 am

   Marco,

   Have you tried telnetting to port 25 on 192.168.1.20? I believe 110 is for POP3, not for sending email. It looks like you successfully sent to your local submit queue, which then gives it off to sendmail to send and it's having trouble contacting the mailhost 192.168.1.20 on port 25 for some reason.

10. Marco Says:
    July 21st, 2008 at 2:07 am

    What I am trying to do is to send a mail from one server to another without DNS. I have sendmail and dovecot in both servers. Shouldn't dovecot accept mails on port 110? Why the telnet to port 25?

11. Florian Says:
    August 6th, 2008 at 9:47 am

    thanks for this! I searched the net and tried for around 2 hours now, but your guide made it finally working

    thanks

    @marco: 110 is the pop3 port. your server does normally not accept any mails there, but you can connect there and receive mails.
    if a mail should get sent to this server he is normally listening on port 25 which is smtp

12. snehal Says:
    February 9th, 2009 at 9:58 am

    thanks it helped me!!
    i guess in submit.mc file should look like this

    FEATURE(`msp', `[your.outgoingserver.com]')dnl
    define(`confDIRECT_SUBMISSION_MODIFIERS', `C')dnl

Installing Sendmail on RHEL4 - Linux Forums

Hello,



I am a newbie in installing sendmail from source. I am trying to install version 8.14.3 on Redhat ES 4. I already have version 8.13.1 that Redhat provided via up2date. How do I install the new version and over right the old version? The doc's I have found don't really provide much help. I have tried the following below and it appears that it did install but when I do a telnet localhost 25 I see two version of sendmail. Please advise.

Thanks,

Chris

Installing sendmail
Download the sendmail source code from the sendmail website.

Extract the files from the downloaded file.
Change the current directory to where the sendmail source code was extracted.
Enter the following command:
sh Build

If there are no errors, you may continue with the installation.
If you are installing sendmail 8.12.x, 8.13.x, or 8.14.x
Verify whether you have a user smmsp. Create the user if it does not exist. The user should not be assigned a login shell.
Verify whether you have a group called smmsp.
Enter the following command:
sh Build install

The sendmail binary is now installed. The next step is to configure sendmail.

Configuring sendmail

The main configuration file for sendmail is the /etc/mail/sendmail.cf file. Starting with version 8.12, sendmail uses the /etc/mail/submit.cf configuration file for mail submission. The .cf files are complex to understand. It is recommended that you create a .mc configuration file and use the M4 (macro processor) to generate the .cf file.

There are some sample .mc configuration files in the cf/cf/ directory of the sendmail source code. Alternatively, you can use one of the sample configuration files available from this website. You should edit the .mc file with a UNIX text editor such as vi.

Change the current directory to cf/cf directory.
Copy your .mc configuration file to the current directory as sendmail.mc.
To generate the sendmail.cf, enter the following command:
sh Build sendmail.cf

To install the sendmail.cf as /etc/mail/sendmail.cf and submit.cf as /etc/mail/submit.cf, enter the following command:
sh Build install-cf

How to troubleshoot RHEL performance bottlenecks by Ken Milberg

09.30.2008

You've just had your first cup of coffee and have received that dreaded phone call. The system is slow. What are you going to do? This article will discuss performance bottlenecks and optimization in Red Hat Enterprise Linux (RHEL5).

Before getting into any monitoring or tuning specifics, you should always use some kind of tuning methodology. This is one which I've used successfully through the years:

1. Baseline – The first thing you must do is establish a baseline, which is a snapshot of how the system appears when it's performing well. This baseline should not only compile data, but also document your system's configuration (RAM, CPU and I/O). This is necessary because you need to know what a well-performing system looks like prior to fixing it.

2. Stress testing and monitoring – This is the part where you monitor and stress your systems at peak workloads. It's the monitoring which is key here – as you cannot effectively tune anything without some historic trending data.

3. Bottleneck identification – This is where you come up with the diagnosis for what is ailing your system. The primary objective of section 2 is to determine the bottleneck. I like to use several monitoring tools here. This allows me to cross-reference my data for accuracy.

4. Tune – Only after you've identified the bottleneck can you tune it.

5. Repeat – Once you've tuned it, you can start the cycle again – but this time start from step 2 (monitoring) – as you already have your baseline.

It's important to note that you should only make one change at a time. Otherwise, you'll never know exactly what impacted any changes which might have occurred. It is only by repeating your tests and consistently monitoring your systems that you can determine if your tuning is making an impact.

RHEL monitoring tools
Before we can begin to improve the performance of our system, we need to use the monitoring tools available to us to baseline. Here are some monitoring tools you should consider using:

Oprofile

This tool (made available in RHEL5) utilizes the processor to retrieve kernel system information about system executables. It allows one to collect samples of performance data every time a counter detects an interrupt. I like the tool also because it carries little overhead – which is very important because you don't want monitoring tools to be causing system bottlenecks. One important limitation is that the tool is very much geared towards finding problems with CPU limited processes. It does not identify processes which are sleeping or waiting on I/O.

The steps used to start up Oprofile include setting up the profiler, starting it and then dumping the data.

First we'll set up the profile. This option assumes that one wants to monitor the kernel.

# opcontrol --setup –vmlinux=/usr/lib/debug/lib/modules/'uname -r'/vmlinux

Then we can start it up.

# opcontrol --start

Finally, we'll dump the data.

# opcontrol --stop/--shutdown/--dump

SystemTap

This tool (introduced in RHEL5) collects data by analyzing the running kernel. It really helps one come up with a correct diagnosis of a performance problem and is tailor-made for developers. SystemTap eliminates the need for the developer to go through the recompile and reinstallation process to collect data.

Frysk

This is another tool which was introduced by Red Hat in RHEL5. What does it do for you? It allows both developers and system administrators to monitor running processes and threads. Frysk differs from Oprofile in that it uses 100% reliable information (similar to SystemTap) - not just a sampling of data. It also runs in user mode and does not require kernel modules or elevated privileges. Allowing one to stop or start running threads or processes is also a very useful feature.

Some more general Linux tools include top and vmstat. While these are considered more basic, often I find them much more useful than more complex tools. Certainly they are easier to use and can help provide information in a much quicker fashion.

Top provides a quick snapshot of what is going on in your system – in a friendly character-based display.

It also provides information on CPU, Memory and Swap Space.

Let's look at vmstat – one of the oldest but more important Unix/Linux tools ever created. Vmstat allows one to get a valuable snapshot of process, memory, sway I/O and overall CPU utilization.

Now let's define some of the fields:

Memory
swpd – The amount of virtual memory
free – The amount of free memory
buff – Amount of memory used for buffers
cache – Amount of memory used as page cache

Process
r – number of run-able processes
b – number or processes sleeping. Make sure this number does not exceed the amount of run-able processes, because when this condition occurs it usually signifies that there are performance problems.

Swap
si – the amount of memory swapped in from disk
so – the amount of memory swapped out.
This is another important field you should be monitoring – if you are swapping out data, you will likely be having performance problems with virtual memory.

CPU
us – The % of time spent in user-level code.
It is preferable for you to have processes which spend more time in user code rather than system code. Time spent in system level code usually means that the process is tied up in the kernel rather than processing real data.
sy – the time spent in system level code
id – the amount of time the CPU is idle wa – The amount of time the system is spending waiting for I/O.

If your system is waiting on I/O – everything tends to come to a halt. I start to get worried when this is > 10.

There is also:

Free – This tool provides memory information, giving you data around the total amount of free and used physical and swap memory.

Now that we've analyzed our systems – lets look at what we can do to optimize and tune our systems.

CPU Overhead – Shutting Running Processes
Linux starts up all sorts of processes which are usually not required. This includes processes such as autofs, cups, xfs, nfslock and sendmail. As a general rule, shut down anything that isn't explicitly required. How do you do this? The best method is to use the chkconfig command.

Here's how we can shut these processes down.
[root ((Content component not found.)) _29_140_234 ~]# chkconfig --del xfs

You can also use the GUI - /usr/bin/system-config-services to shut down daemon process.

Tuning the kernel
To tune your kernel for optimal performance, start with:

sysctl – This is the command we use for changing kernel parameters. The parameters themselves are found in /proc/sys/kernel

Let's change some of the parameters. We'll start with the msgmax parameter. This parameter specifies the maximum allowable size of a single message in an IPC message queue. Let's view how it currently looks.

[root ((Content component not found.)) _29_139_52 ~]# sysctl kernel.msgmax
kernel.msgmax = 65536
[root ((Content component not found.)) _29_139_52 ~]#

There are three ways to make these kinds of kernel changes. One way is to change this using the echo command.

[root ((Content component not found.)) _29_139_52 ~]# echo 131072 >/proc/sys/kernel/msgmax
[root ((Content component not found.)) _29_139_52 ~]# sysctl kernel.msgmax
kernel.msgmax = 131072
[root ((Content component not found.)) _29_139_52 ~]#

Another parameter that is changed quite frequently is SHMMAX, which is used to define the maximum size (in bytes) for a shared memory segment. In Oracle this should be set large enough for the largest SGA size. Let's look at the default parameter:

# sysctl kernel.shmmax
kernel.shmmax = 268435456

This is in bytes – which translates to 256 MG. Let's change this to 512 MG, using the -w flag.

[root ((Content component not found.)) _29_139_52 ~]# sysctl -w kernel.shmmax=5368709132
kernel.shmmax = 5368709132
[root ((Content component not found.)) _29_139_52 ~]#

The final method for making changes is to use a text editor such as vi – directly editing the /etc/sysctl.conf file to manually make our changes.

To allow the parameter to take affect dynamically without a reboot, issue the sysctl command with the -p parameter.

Obviously, there is more to performance tuning and optimization than we can discuss in the context of this small article – entire books have been written on Linux performance tuning. For those of you first getting your hands dirty with tuning, I suggest you tread lightly and spend time working on development, test and/or sandbox environments prior to deploying any changes into production. Ensure that you monitor the effects of any changes that you make immediately; it's imperative to know the effect of your change. Be prepared for the possibility that fixing your bottleneck has created another one. This is actually not a bad thing in itself, as long as your overall performance has improved and you understand fully what is happening.

Performance monitoring and tuning is a dynamic process which does not stop after you have fixed a problem. All you've done is established a new baseline. Don't rest on your laurels, and understand that performance monitoring must be a routine part of your role as a systems administrator.

About the author: Ken Milberg is a systems consultant with two decades of experience working with Unix and Linux systems. He is a SearchEnterpriseLinux.com Ask the Experts advisor and columnist.

Recommended Links

Mail Transport Agents

How to troubleshoot RHEL performance bottlenecks by Ken Milberg

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019