On 1/18/06 1:22 AM, "Nigel Wade" <[EMAIL PROTECTED]> wrote:
> I'm in the process of deciding how to configure our mail server to provide > client submission (port 587, and possibly 465). I'm looking for general tips, > and do's and dont's for its configuration. The purpose is to allow > authenticated > client submission over SSL from the Internet. We are not able to allow port 25 > submission, hence the requirement to setup port 587/465. Be aware that Outlook Express politely declines to use STARTTLS except on port 25. You need SSL-on-connect on some port for those users. Many sites find it convenient to use port 465 for that, and 587 for STARTTLS. That is sort of standard. As you've noted, others do things differently. And if you have any Macintosh Outlook Express users (we still do), you need to deal with its problems authenticating...it works over ssl-on-connect on port 465. We developed but never installed an Exim patch to cater to those users. > > I'm currently leaning towards the idea of a separate Exim process handle mail > submission, and for this to relay the mail to the main Exim process for > delivery. I'm hoping that will be easier to setup and maintain than a single > configuration. We elected, in 2002, to use two Exim instances, servicing different IPs (we kept the smtp.olympus.net name for submission, since that's what many users were set up with, and created a new name for the MX for the world to use (only on port 25). We also do some mail processing outside Exim, and this processing differs between the customer-submitted mail and the world-provided mail. Our "customer Exim" sends mail to the world, but sends mail destined to our customers over to the world side for "incoming" processing before delivery. I don't see a benefit to sending the world-bound mail through both Exim instances. We might or might not elect to use a single instance were we building the system from scratch today but with the experience we have gained. One annoyance with dual Exim instances is that exiwhat needs attention in order to report "the wrong one". We do our two Exim instances using -C other-config on the command line of the customer instances, with the same binary. It's also handy to have shell aliases to run things like exim -bp for the instance which needs the -C blah command line. We elected to log into different directories but with the normal log file names--there are times I wish we logged into one directory with different file names, and other times when the way we selected seems better. And because of Netscape 4 (which can't remember the authentication password), we actually have two customer submission IPs, one of which does not advertise STARTTLS on port 25, the other of which does (and was our old MX). But submitting via this IP requires either coming from a suitable IP address or authenticating via an alternate port. This showed up the fact that many spammer operations remember the IP to use, and use it long--years--after the MX record has changed. Others here have remarked about that. We have multiple machines, with common configurations maintained in Subversion, and patched in a machine-specific way by an install script. [The writer of that selected patch--sed could have been used.] This works well for us. Some of our ACLs are maintained in one file which is included by both instances, and there are other similar uses of common files which are read. I'm not sure the maintenance benefit of the common included ACLs outweighs the human reading difficulty. Mr. Hacker, with his tightly-controlled user base, has the luxury of doing things very differently. --John (who went through the Exim 2 to Exim 3 conversion ;-)) -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
