On 2/3/11 8:31 PM, Joe wrote:
On 02/03/2011 11:24 AM, James R. Marcus wrote:
Hi,
I have been reading about prioritizing mail in Postfix on this list.
It seems that the answer is, there is a shared queue and mail is not
prioritized. I want to make sure that I fully understand if this
applies to my situation.
All of our servers that send mail go through our Postfix gateways. I
don't want to manage our exchange server as a relay.
I find that when we send out a lot of email and there is mail queued,
internal mail is delayed. I'm assuming the short term solution to
this is:
postqueue -s domain.com
Is there another way to prioritize internal mail delivery based on
domain?
Postfix-2.3.3-2.1.el5_2 running on CentOS 5.5 x64
One huge improvement you can make is to specify the "relay" transport
for incoming mail.
To achieve what ?
That will create a separate queue from the outgoing mail which is
using the "smtp" transport,
There is one queue.
The qmgr(8) does not make priority or precedence decisions based on the
transport:nexthop information of queued mail; all eligible mail is
processed ASAP (in the incoming and active queues) or when its time is
up (in the deferred queue).
If you want to prioritize mail, you can create a separate postfix
instance with postmulti(1) so there really will be 2 queues.
These can then process and deliver mail bound for specific destinations
- internal vs. external, for instance.
Their queue performance will still depend largely on your disk I/O
subsystem's capabilities, but the qmgr(8) itself will no longer be the
bottleneck for internal mail vs. the slower-moving external mail,
because there will be two of them, each able to fully utilize a single CPU.
Based on your post, however, the disk I/O subsystem is most likely the
bottleneck for you.
Of course, another logical solution is to just set up a different
machine to handle internal mail, thereby completely bypassing the
bottleneck.
Personally, I would set up a mail destination for the entire network
(optionally load-balanced), which has the resources to at least decide
what to do with all mail, and can then hand off internal mail to an
internal mail store and/or back to the exchange servers, and hand off
outgoing mail to dedicated SMTP senders that do nothing else.
If you separate all auxiliary functions from the core routing, the core
routing can be very fast; of course, you would have to scale the queue
subsystem to match.
--
J.