Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Running several instances of sendmail

Sendmail_Multi_SMTP_Port

Re multiple instances of sendmail

On Wed, Jan 26, 2005 at 12:15:41PM -0800, stupidmail4me wrote:
> Is it possible to have more then one instance of
> sendmail running on the same machine?

Yes.

> The server is listening to two IPs, and I want to bind
> one sendmail instance to one of them and have it
> functioning with a normal smtp configuration. On the
> other IP I want to bind sendmail with a mailing list
> configuration. Is this possible and how would I go
> about doing it?

One way is to provide separate configuration files for each daemon.  The
following is provided in the default, and is what you want to change in
each configuration to bind to specific IP addresses.

  FEATURE(`no_default_msa')dnl
  DAEMON_OPTIONS(`Family=inet, Address=0.0.0.0, Name=MTA')dnl
  DAEMON_OPTIONS(`Family=inet6, Address=::, Name=MTA6, M=O')dnl
  DAEMON_OPTIONS(`Family=inet, Address=0.0.0.0, Port=587, Name=MSA, M=E')dnl
  DAEMON_OPTIONS(`Family=inet6, Address=::, Port=587, Name=MSA6, M=O, M=E')dnl

You might want to look at CLIENT_OPTIONS as well.  You specify which
configuration file to use with the -C option to sendmail.  Just start
the second instance from /etc/rc.local with the appropriate options.

 

Running a second sendmail instance

Situation: We want to separate core mail from "higher-risk" mail (i.e. mail sent from application servers in a DMZ) on our sendmail servers. In the event that one of our DMZ servers for which we relay mail is compromised, we do not want our mail server placed on a DNS blacklist. Therefore, we will have separate IP addresses for core mail and "higher-risk" mail. In this example, the system has only one physical network interface, so we will create and enable a virtual interface for "higher-risk" mail.

1. Create and enable the virtual interface. In this example, the primary network interface is eri0 with IP address 192.168.1.1. The virtual interface has an IP address of 192.168.1.2, and has a fully-qualified domain name of virt-int.example.com.

# ifconfig eri0:1 plumb
# ifconfig eri0:1 192.168.1.1 netmask 255.255.255.0 up

2. Modify /etc/hosts and /etc/hostname.eri0:1 to enable the virtual interface after each system boot.

# echo "virt-int" > /etc/hostname.eri0:1
# echo "192.168.1.1\tvirt-int.example.com\tvirt-int" >> /etc/hosts

3. Make a copy of the main sendmail.mc file. This copy will be used to configure the second sendmail instance.
$ cp sendmail.mc virt-int.mc

4. By default, the main sendmail instance will bind to TCP port 25 on all network interfaces. We want the main sendmail instance to only bind to TCP port 25 on its IP address and the localhost interface. In the main sendmail.mc file, add the following lines:

DAEMON_OPTIONS(`Addr=192.168.1.1')dnl
DAEMON_OPTIONS(`Addr=127.0.0.1')dnl

By default, the sendmail mail submission agent (MSA, used to submit mail on the local system to an MTA) attempts to connect to an MTA on the localhost (127.0.0.1) interface. The second line above binds the primary sendmail instance to the localhost interface in addition to its IP address. The MSA configuration file, submit.mc, could have instead been modified to use the MTA on the primary interface or the virtual interface.

5. Configure the second sendmail instance by adding the following lines to virt-int.mc:

FEATURE(no_default_msa)dnl
define(`QUEUE_DIR',`/var/spool/mqueue/virt-int/q*')dnl
define(`confPID_FILE',`/var/run/sendmail_virt-int.pid')dnl
define(`confDOMAIN_NAME',`virt-int.example.com')dnl
CLIENT_OPTIONS(`Addr=192.168.1.2')dnl

DAEMON_OPTIONS(`Addr=192.168.1.2')dnl

The first line above prevents the second sendmail instance from attempting to start its own Mail Submission Agent (MSA) on TCP port 587. The main sendmail instance will have its own MSA bound to this port, and the second sendmail instance will not start if it attempts to also bind to TCP port 587.

The second line specifies an alternate mail queue directory for the second sendmail instance. If mail processed by the second sendmail instance cannot be immediately delivered, it will be queued. If mail queue directories are not separated for the two sendmail instances, the main sendmail instance's queue runner could process mail queued by the second sendmail instance.

The third line specifies a process ID (PID) file for the second sendmail instance. Having a separate PID file makes it easy to stop the second sendmail instance from an /etc/init.d script.

The fourth line populates sendmail's $j macro with the fully-qualified domain name of the second sendmail instance. Without it, mail processed by the second sendmail instance may contain hostname information of the main sendmail instance.

The fifth line is needed so that the second sendmail instance uses its IP address when acting as a client (i.e. when relaying mail).

The sixth line is needed to bind the second sendmail instance to the virtual interface.

Note: if you use RELAY_DOMAINS_FILE in virt-int.mc and do not want values from /etc/mail/relay-domains in class R, you must add undefine(`confCR_FILE') to virt-int.mc.

Otherwise, entries from both /etc/mail/relay-domains and the file specified in RELAY_DOMAINS_FILE will be added to class R. This is because cf/m4/cfhead.m4 populates confCR_FILE with /etc/mail/relay-domains by default.

If you use confCR_FILE instead of RELAY_DOMAINS_FILE in virt-int.mc to populate class R, the confCR_FILE value in virt-int.mc will supersede cf/m4/cfhead.m4, and only entries from confCR_FILE in virt-int.mc will be listed in class R.

6. Create the mail queue directory for the second sendmail instance.
# mkdir -p /var/spool/mqueue/virt-int/q1 /var/spool/mqueue/virt-int/q2 \ /var/spool/mqueue/virt-int/q3 /var/spool/mqueue/virt-int/q4 /var/spool/mqueue/virt-int/q5

7. Build and install the sendmail configuration files.

$ ./Build sendmail.cf
$ ./Build virt-int.cf
# cp sendmail.cf virt-int.cf /etc/mail

8. Reread the configuration file of the main sendmail instance.
# kill -HUP `head -1 /var/run/sendmail.pid`

9. Start the second sendmail instance.
# sendmail -L sm-mta-virt-int -C /etc/mail/virt-int.cf -bd -q30m

10. Modify the sendmail startup and shutdown script for the second sendmail instance.

/etc/init.d/sendmail changes in bold.

#!/bin/sh

case "$1" in
'start')
   # Start the MTA
   /usr/lib/sendmail -L sm-mta -bd -q30m
   # Start the second MTA instance
   /usr/lib/sendmail -L sm-mta-virt-int -C /etc/mail/virt-int.cf -bd -q30m
   # Start the MSP
   /usr/lib/sendmail -L sm-msp-queue -Ac -q30m
   ;;
'stop')
   # Stop the MTA
   [ -f /var/run/sendmail.pid ] && \
/usr/bin/kill `/usr/bin/head -1 /var/run/sendmail.pid`

   # Stop the second MTA instance
   [ -f /var/run/sendmail_virt-int.pid ] && \
/usr/bin/kill `/usr/bin/head -1 /var/run/sendmail_virt-int.pid`

   # Stop the MSP
   MSP_PID=`/usr/bin/ps -e -o pid,args | /usr/bin/grep [s]m-msp-queue | \
/usr/bin/awk '{print $1}'`

   [ -n "$MSP_PID" ] && /usr/bin/kill $MSP_PID
   ;;
*)
   echo "Usage: $0 { start | stop }"
   exit 1
   ;;
esac
exit 0

 

Running multiple sendmail instances on same server Nix World

This post by Manoj Chauhan is a derivative of the post by Running a second sendmail instance but does not contain a proper reference to the original.
February 21st, 2010  | Nix World
 

Situation:

 We want to separate core mail from “higher-risk” mail (i.e. mail sent from application servers in a DMZ) on our sendmail servers. In the event that one of our DMZ servers for which we relay mail is compromised, we do not want our mail server placed on a DNS blacklist. Therefore, we will have separate IP addresses for core mail and “higher-risk” mail. In this example, the system has only one physical network interface, so we will create and enable a virtual interface for “higher-risk” mail.

To setup multiple instances we need to have multiple IP address. We can add the multiple IPs in the linux server by using multiple network cards or by creating network card aliases. Network Aliases can be created by using the following way

 

1. Copy ifcfg-eth0 to ifcfg-eth0:0 (cp ifcfg-eth0 ifcfg-eth0:0)
2. Modify ifcfg-eth0:0 accordingly and assign new IP address. We can modify to ifcfg-eth0:0 same as below

# Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE]
DEVICE=eth0:0
BOOTPROTO=static
BROADCAST=172.16.31.255
IPADDR=172.16.23.168
GATEWAY=172.16.16.1
NETMASK=255.255.240.0
NETWORK=172.16.16.0
ONBOOT=yes

3. Then up the newly created the network aliases, we can up it by using this command
# ifup ifcfg-eth0:0
4. To down the network aliases use this command #ifdown ifcfg-eth0:0
5. To verify newly created network aliases we can use the following command
# /sbin/ifconfig
  
By default, the sendmail mail submission agent (MSA, used to submit mail on the local system to an MTA) attempts to connect to an MTA on the localhost (127.0.0.1) interface. The second line above binds the primary sendmail instance to the localhost interface in addition to its IP address. The MSA configuration file, submit.mc, could have instead been modified to use the MTA on the primary interface or the virtual interface.

1. create copy of main sendmail.mc file to new file mx2snalert.cf
2. Modify mx2snalert.mc accordingly and add the following line in the mx2snalert.mc

 

define(`QUEUE_DIR’,`/var/spool/mqueue/mx2snalert/q*’)dnl
define(`confPID_FILE’,`/var/run/sendmail_mx2snalert.pid’)dnl
define(`confDOMAIN_NAME’,`mx2.snalert.net’)dnl
CLIENT_OPTIONS(`Addr=172.16.23.168′)dnl
DAEMON_OPTIONS(`Addr=172.16.23.168′)dnl
 
3. Save the mx2snalert.mc after modification
4. Create mx2snalert.cf file by using mx2snalert.mc. We can convert the mx2snalert.mc to mx2snalert.cf file by using the following command

#m4 /etc/mail/mx2snalert.mc > /etc/mail/mx2snalert.cf

5. Before starting the new instance we need to create the individual queue for individual instance.
6. We can create the individual queue by using the following commands
#mkdir /var/spool/mqueue/mx2snalert/
# mkdir /var/spool/mqueue/mx2snalert/q{1,2,3,4,5,6,7,8}
# Change the ownership of  mqueue folder.
#chown -R root:mail /var/spool/mqueue/
Also change the permission of the queue folder i.e. mqueue
#chmod –R 777 /var/spool/mqueue/

7. Reread the configuration file of the main sendmail instance.
# kill -HUP `head -1 /var/run/sendmail.pid`
8. Start the second sendmail instance.
# sendmail -L mx2snalert -C /etc/mail/ mx2snalert.cf -bd -q30m
9. We can check the status of the newly created instances by using following command

# netstat -an | grep 25
tcp  0  0 172.16.23.170:25    0.0.0.0:*  LISTEN
tcp  0  0 172.16.23.169:25    0.0.0.0:*  LISTEN
tcp  0  0 172.16.23.168:25    0.0.0.0:*  LISTEN
tcp  0  0 172.16.23.167:25    0.0.0.0:*  LISTEN

10. Now we can test new instance by sending test mail, we can send the mail by using telnet command

telnet 172.16.23.168 25
helo companydomain.net
mail from: adp@domain.com
rcpt to: mchauhan@onaxer.com
data
subject: Testing
message body
. (Enter dot to terminate the message body)

11. We can create multiple sendmail instances by using the above steps.  

Thanks
Manoj Chauhan


Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended

Top articles

Sites

Running Multiple Sendmail Instances on a Debian-like System (Ubuntu 10.4 LTS Server)

SENDMAIL: Listening to multiple SMTP ports on a single mail server instance

README.sendmail-dual



Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard 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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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-MonthHow 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


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

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.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: June 04, 2016