Re: [exim] Faking an external SMTP server authenticated and …

On Wed, 2013-01-30 at 15:24 +0100, Marco Gaiarin wrote:
> In our organization there's a well-defined (and mostly exim-based) internal
> (on the WAN) email routing. Internally every site have a 'mail' aliases that
> point to un-authenticated and un-encrypted local server, so mobile users can
> move from site to site and send email transparently.
>
> But we have also some other users that use an external domain (say
> verylongname.it), and so receive email via IMAPS from imap.verylongname.it
> and send email (authenticated and encrypted) to mail.verylongname.it.
>
> But for now, and i think for a long time, most of the recipient will be
> internal, so it is really stupid to simply ''pinhole'' the firewall and let
> the email to go out, to see them get back from the border gateway.
>
> I'm thinking about:
>
> 1) overload 'mail.verylongname.it' in the internal DNS, and this is very
> easy.

> 2) enable TLS on exim, and configure it to simply ignore authentication (or,
> better, accept for 'mail.verylongname.it' any user and password provided).
>
>
> The only trouble remain the certificates mess (the internal server reply as
> the external one, but with a wrong certificates) but i think this can be
> cured client-side.

I assume that 'verylongname.it' is under your control and you can obtain
SSL certificates for it? So you could just use such a cert on port 587
of your internal mail server. Your submission to the public server is
obviously done on port 587, right? And not currently used internally? So
you could use whatever cert you like for that, regardless of the cert
you're using on port 25 for STARTTLS (if you're using one at all).

In general though, unless your bandwidth is extremely limited and
latency is extremely problematic (or your users are sending particularly
large emails), I would be very hesitant to violate the KISS principle.
This kind of special-case hack has a *large* tendency to introduce
unforeseen problems.

--
dwmw2