8 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Newbie: mail queu...
FromSent OnAttachments
Colin DickSep 6, 2003 10:33 am 
Mircea DamianSep 7, 2003 1:10 am 
Mircea DamianSep 7, 2003 8:44 am.pl
Gordon MessmerSep 7, 2003 6:50 pm 
Evelyn PichlerSep 8, 2003 10:28 pm 
Colin DickSep 9, 2003 10:23 pm 
Gordon MessmerSep 9, 2003 11:50 pm 
Mitch (WebCob)Sep 9, 2003 11:51 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [courier-users] Newbie: mail queue optimization.Actions...
From:Gordon Messmer (yiny@eburg.com)
Date:Sep 7, 2003 6:50:41 pm
List:net.sourceforge.lists.courier-users

Colin Dick wrote:

As far as I can tell, I am getting more mail than I am able to process through the memory based queue during peak times and the messages are getting dumped to the disk based queue.

Many of courier's default settings are too low for a large scale server. My first suggestion would be to use the default queuefill/queuehi/queuelo settings, and instead increase the values of MAXDELS in /etc/courier/module.local and /etc/courier/module.esmtp. After you've found good values for MAXDELS, then consider playing with the other settings if you need to.

I have many message (mostly bounce messages to spoofed senders) that are old and are taking up the space in the memory queue when it reloads due to my queuefill value (15m).

You might consider using my "pythonfilter" with the dialback module. This should eliminate mail "from" undeliverable addresses: http://phantom.dragonsdawn.net/~gordon/courier-patches/courier-pythonfilter/

How would I reserve some space in the memory queue for new local deliveries? In other words prioritize for the local users on the box.

I believe local deliveries are already given priority. Check the PRIORITY value in module.local.

The computer is a P4 1.60GHz (cpu MHz : 1615.935) running on RH9.0. We recently doubled the RAM from 512 to 1G which helped the speed of Squirrelmail, however, the queue just won't process fast enough.

The other possibility you might consider is this: If the one system just isn't fast enough, branch out. Export /home on the existing system, and then set up an identical machine running all of the same software (you'll need new RAV licenses, and I'm not sure how you'll handle that situation), but mount /home from the other box. Make this an alternate MX either by adding its IP address to the hostname currently listed as your MX, or by adding a new hostname to your domain's MX records with a priority equal to the server you're currently using. This way you can balance the work across several machines for better performance. I favor the approach of using multiples IP addresses for the hostname in your MX record because then your users will also balance their POP/IMAP sessions across the cluster.

Good luck.