Mailqueue and errorhandling questions..
Hi
After a major power failure our mailserver, IMS 5.2, had an abrupt shutdown. After some startup problems the mailserver seems to work ok, except for one thing. We had a big backlog of mails built up in our two external relays and when the mailserver went up, all these mails were delivered to the mailserver. The result: at the moment 65 000 mails in the ims-ms mailqueue. My questions is as follows:
As I understand it the best way is to let the mailserver work it磗 way through the mail in the queue to get all mails delivered. The problem is that it takes to long time and I want to speed this up if possible.
Is there a way to make the mailserver handle the ims-ms queue with a higher priority ?
To decrease the workload we would like to stop messages being generated to the postmaster account for mail that don磘 have a correct mailaddress to users in our domain. You could do that in the older versions of the server but I can磘 find where to change this in IMS 5.2.
Is there a way to configure this in IMS 5.2 even if it means that the mailserver won磘 give any errormessages in return to the sender?
Regards
/BNs
[1168 byte] By [
BNs] at [2007-11-26 11:21:24]
# 1
My first question is, why is your server attempting to handle mail that's not addressed to your users in the first place?
The best place to check for validity of users is when you first touch the message, at the outermost MTA. That way, you simply don't accept the message at all, and reject it with an SMTP error.
Now, you have to create a DSN (Delivery Status Notice), and send it, likely to a non-existant, or unhappy "joe-jobbed" fake return address. Not good. This can also get your server blacklisted.
Now, if it's YOUR postmaster messages you're worried about, you can put "nocopypost" and "nosendpost" keywords on any channels that need it, then run:
imsimta cnbuild
imsimta restart
Depending on your version of 5.2, we MAY be able to help you drain the queue quicker, though likely that's going to be limited by your disk's ability to actually write the bits down. That's always the ultimate limit.
Please run:
imsimta version
and post the results, here. If I can help you drain your ims-ms queue, I will.
Not sending DSN to the outside world is definitely something you should never attempt doing. That way lies lost mail.
# 2
The answer to the first question is that relayservers we are using for antivirus etc. is based on a technology that don磘 speak ldap, so no communication with the ldap-server. We are aware that this is quite bad and are working on another solution.
The idea behind the question about the postmaster mails was to make more resources available for the mailserver to handle the queues. As it is, it seems that the mails from the past days are starting to show up and that this is not necessary anymore. It would, however, be interesting to know possible ways to drain the ims-ms queue if the need will arise in the future.
We are running IMS 5.2 patch 1
//BNs
BNs at 2007-7-7 3:36:47 >
# 3
You need to upgrade to at least Patch 2, available free at the Sun download site.
Then you can increase the "maxjobs" number in the imta.cnf file for ims-ms channel from 1 to 2 or 3, assuming you don't just run out of disk i/o.
Messaging 6 defaults to 2, and can go higher.
I would personally replace your relayservers with Messaging Server MTAs. Messaging 6.2 can install just the MTA part. Same cost as what you already have, as cost is calculated by user/mailbox, not cpu or number of installs.
Have the MTAs do ldap lookups, and reject bad address mails immediately. Much better for the rest of your network,.
# 5
Hi,
The following is a good guide on tuning:
http://ims.balius.com/resources/downloads/files/iMS-Tuning-Guide.21.pdf
Although these hints/tips can offer small improvements, as Jay noted messaging server is very much I/O restricted when it comes to delivering a large number of emails to the store via ims-ms.
Therefore reducing the number of emails coming in, setting store.dbtmpdir to /tmp/msg-<instance> (memory mapped filesystem) and if possible having the mbox database on a separate lot of disk spindles are your best bet.
Regards,
Shane.
