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. All beyond your control... HTH, Bill -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
