Autor: W B Hacker Data: Para: exim users Asunto: Re: [exim] tweaking communication between private and public exim
MTA
AJ wrote: > Hello,
>
> For one reason and another, in our environment, we have an exim MTA on our
> private network, that clients on the 'private side'(LAN) use to send
> Internet Email. This server then relays via private IP, to a second exim we
> have connected to the public Internet. The public server is tuned to conform
> to standards avoiding 'tar pitting', etc.
>
> That all being said, I'd appreciate some hints on tuning the communications
> between the private server and the public server. Some local users
> occasionally send to reasonably long lists of their clients. Since the
> private & public servers talk via private LAN, this communication can be
> wide open.
>
> What I'm trying to avoid is doing something on the public server that would
> make it non-compliant with the 'norms' of the large carriers, while I try to
> make it more receptive to the private server. I'm trying to make the private
> server respond quickly to clients and get it's email pushed to the public
> server as quickly as possible.
>
> I hope the above scenario makes sense. Below is some of what I've done so
> far.
>
> I appreciate any advice, so I don't shoot myself in the foot!.... AJ
>
> Private server:
> ----------------------
> split_spool_directory = yes
> queue_run_max = 20
> remote_max_parallel = 20
> #connection_max_messages 40
> disable_fsync = true
>
> smtp_accept_max = 1000
> smtp_accept_max_per_connection = 4000
> smtp_accept_queue_per_connection = 100
> smtp_accept_max_per_host = 200
>
> Public Server:
> ---------------------
> split_spool_directory = yes
> queue_run_max = 20
> remote_max_parallel = 20
> disable_fsync = true
>
> smtp_accept_queue_per_connection = 100
Before I'd split the spool, I'd split the load over one or more additional
boxes. Linking both to the 'public' AND 'private' networks, then and giving each
BOTH 'personality' sets is not hard for Exim.
That way - if/as/when either box goes tits up, you have another that can still
carry a load even if more slowly More to the point - only half (or fewer) of
your user-community tying you up on the phone complaining when you actually want
to be free to concentrate on fixing the problem.
That also lets you list a fallback MX AND originate from two separate IP so that
far-end connection-per-IP limits (if any) are less of a barrier.
Absent reconfiguring, a purchased or leased extra server might be cheaper than
your time - or risk.
But even without that...
- do you utilize and test for a separate arrival IP and/or port to make it
easier to craft rules specific to the internal box and/or skip-over rules
specific to external submissions? I could be wrong, but I think it takes fewer
resources to test for the arrival port than presence in a relay_from or similar
hostlist or lookup source.
- do you make use of a bespoke port as well as /instead of (just) the bespoke
IP. Ex: Port 24. Same again w/r 'cheaper' tests.
IMNSHO, skipping all acl tests - and even more so SA scans (I'd keep ClamAV
scans) that are not needed on internal submissions is more likely to free up
resources and reduce delsys than anything you do with the spool.
On any hardware more capable than a VIA C6, (quite decent BTW) by the time a
bog-standard Exim configuration starts to strain under load, the number of
clients or their traffic is usually high enough that one is 'at 'risk' to not
have a fallback box on at least hot-standby/manual IP-takeover.
Not to forget - the far-end doesn't often care how well you have tweaked your
server. Most destinations will move at their own pace regardless - including
greylisting and imposed delays within the smtp session.
