Reccommended SMTP settings
Greetings, we've recently ran into a problem where our msg server will refuse connections to other mail servers. I assume that it is a DOS issue becuase are mail server is busy and doesn't have any open connections.
For my first questions i was wondering thoughts on this, does my assumption sound correct?
Second Question, what are the recommended settings for the job_controller and dispatcher for high volume servers (~between 500k and sometimes 1 millions messages every 24 hours).
Right now these are the settings..
root@msg0 # imsimta version
Sun Java(tm) System Messaging Server 6.2-7.05 (built Sep 5 2006)
libimta.so 6.2-7.05 (built 12:18:44, Sep 5 2006)
SunOS msg0 5.9 Generic_118558-35 sun4u sparc SUNW,Sun-Fire-V440
root@msg0 #
DISPATCHER.CNF
MIN_PROCS=1
MAX_PROCS=10
MIN_CONNS=30
MAX_CONNS=50
MAX_SHUTDOWN=2
MAX_LIFE_TIME=86400
MAX_LIFE_CONNS=10000
MAX_IDLE_TIME=600
HISTORICAL_TIME=0
JOB_CONTROLLER.CNF
--
[POOL=DEFAULT]
job_limit=10
!
[POOL=LOCAL_POOL]
job_limit=10
!
[POOL=IMS_POOL]
job_limit=2
!
[POOL=SMTP_POOL]
job_limit=10
!
!Channel definitions
!
[CHANNEL=bitbucket]
master_command=IMTA_BIN:bitbucket
!
[CHANNEL=bsmtp*]
master_command=IMTA_BIN:bsout_master
slave_command=IMTA_BIN:bsin_master
!
[CHANNEL=conversion*]
master_command=IMTA_BIN:conversion
!
[CHANNEL=defragment]
master_command=IMTA_BIN:defragment
!
[CHANNEL=ims-ms*]
max_life_age=14400
max_life_conns=20000
master_command=IMTA_BIN:ims_master
!
[CHANNEL=native]
master_command=IMTA_BIN:l_master
!
[CHANNEL=pipe*]
master_command=IMTA_BIN:pipe_master
!
[CHANNEL=printer*]
master_command=IMTA_BIN:printer
!
[CHANNEL=process*]
master_command=IMTA_BIN:reprocess
!
[CHANNEL=sms*]
master_command=IMTA_BIN:sms_master
!
[CHANNEL=tcp_*]
master_command=IMTA_BIN:smtp_client
!
[CHANNEL=reprocess*]
master_command=IMTA_BIN:reprocess
!
[CHANNEL=uucp_*]
master_command=IMTA_BIN:uucp_master
slave_command=IMTA_BIN:uucp_slave
!
[CHANNEL=hold]
!
[CHANNEL=filter_discard]
Thanks in advance!
-- Jeremy
# 1
Jeremy, there are many settings you can play with. I have no specific recommendations to make, as "high volume" means very different things to different people.
I can suggest looking at the unofficial "Tuning Guide" for specific suggestions. It's here:
http://ims.balius.com/resources/downloads/files/iMS-Tuning-Guide.21.pdf
To start tuning, you need to understand how the MTA works:
1. The Job Controller allocates a "pool" of "jobs" for your various channels. The default is for 10 jobs for "smtp_pool"
2. Your imta.cnf file uses those jobs for the various channels, the "maxjobs" keyword. You will find that the smtp pool is drawn on by several channels, each with a default of 7 jobs. If all the channels get busy, you will run out of jobs in the pool. Check your logs for an error message for this.
Each job handles a maximum number of connections at one time (max_conns).
It's rather an art and a balancing act to configure this optimally. Chad Stewart, the author of the Tuning Guide is one of the very best at it.
# 2
Hi,
Firstly.. I agree with everything Jay said. Tuning is not something that can be easily done via the forum. The "recommended" SMTP settings are those that are provided by default. Settings for large throughput sites such as yourself are going to be different - how different depends on numerous factors including hardware available, traffic patterns, spam/virus filtering requirements, end-user requirements, existing mapping/routing ruleset, version of software etc.
> Greetings, we've recently ran into a problem where
> our msg server will refuse connections to other mail
> servers. I assume that it is a DOS issue becuase are
> mail server is busy and doesn't have any open
> connections.
One thing needs to be clarified. Was the problem sending TO other systems (outgoing email), or receiving emails FROM other systems (incoming). This will influence whether you need to tune the dispatcher.cnf (incoming) or the job_controller.cnf/imta.cnf (outgoing). Be aware though that increasing incoming will obviously result in more outgoing traffic... this will only move the bottleneck and not necessarily solve the underlying issue (which may well be that you need more hardware).
> For my first questions i was wondering thoughts on
> this, does my assumption sound correct?
Hard to tell from the limited information.
> Second Question, what are the recommended settings
> for the job_controller and dispatcher for high volume
> servers (~between 500k and sometimes 1 millions
> messages every 24 hours).
You need to monitor the current systems (connection times, transit times etc.) to determine a benchmark of what the current performance is. Otherwise even if we did recommend changes, how would you know if they made an improvement or made the situation worse.
If you want to supply your email address I will send you a copy of the imslog.pl script which you can use to analyse your current mail.log files to see how well the various channels are performing. This will give you a good starting point on whether the bottleneck in outgoing emails are.
Shane.
# 3
First off, thank you Jay and Shane for the advise.
To clarify, this is email coming into my server. I do plan to look through the logs, but I posted before on my assumption.
Following Jay's advise I will read the guide and look at the logs.
Shane, I have the script already and have run it, but I'm not sure on how to interpret the data. What should I look for and how do I translate it to performance?
Thanks again!
# 4
Hi,
> To clarify, this is email coming into my server. I
> do plan to look through the logs, but I posted before
> on my assumption.
Ok, so we are looking at dispatcher.cnf performance. What was the overall load on the system like when the service wasn't responding? You can increase the number of connections that the dispatcher can handle (refer to the tuning guide, section 8.1 - dispatcher tuning)) but as I noted this may just cause further problems. Sometimes slow service response is a good thing (protects the rest of your organisation from email floods).
> Shane, I have the script already and have run it, but
> I'm not sure on how to interpret the data. What
> should I look for and how do I translate it to
> performance?
You need to look at queue delay time and look for hosts that have numerous failures.
e.g. destination domains such as yahoo.com usually need their own channel created because the yahoo mail hosts tend to respond slowly and fail a lot, thus creating a backlog of emails. This processing also causes other emails in the same channel (tcp_local) to back-up.
We have a number of customers who have this particular issue.
Shane.
