Re: [exim] Setup for authenticated submission

On 1/18/06 1:22 AM, "Nigel Wade" <nmw@???> 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 ;-))