Thanks everyone. It seems I have quite a lot of information to be getting on
with. I just want to follow up on some points...
Jakob Hirsch wrote:
> Nigel Wade 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.
>
>
> It depends on your requirements.
> I have only one rule: You have to AUTH before you can submit. I have also
> disabled AUTH on port 25, but that's optional.
Port 25 isn't an option for us, it's already blocked. That's one of the reasons
for enabling the submission ports.
>
>
>>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
>
>
> I don't see why you should do that. It complicates things unnecessarily.
> But that, again, depends on your requirements.
>
One thing which puzzles me is that everyone is of the opinion that a single
Exim, with everything rolled into one config. is simpler. I don't get this. I
really would have expected it to be simpler and cleaner, to separate the roles,
with less chance of rules for one role interfering with the other. I'd already
looked at Tony's config. for Exim at Cambridge, and those multiple
"personalities" and the multiplicity of ACLs was one reason I thought separating
the roles would make life easier.
Also, with separate processes, it should be possible to completely separate the
mail submission from the MTA functions, so I can shut down either submission or
MTA roles without affecting the other, and can test each in isolation.
Am I missing something obvious, which would make this more complicated than I
think it might be?
> I also saw somebody having port 587 in tls_on_connect, which I think is a
> bad idea. While RFC 2476 does not explicitly specify it, all installations
> I know of use STARTTLS.
>
If you rely on STARTTLS, is it possible to enforce STARTTLS *before*
authentication, so some user doesn't configure their MUA to send their
credentials unencrypted? Since this is to allow non-local submission I don't
want this information being sent unencrypted.
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@???
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
