Re: [exim] Sending e-mails to a remote location with the sam…

Harold Zwier wrote:

> I am setting up exim at the head office of a company whose domain
> name is (say) smile.com
>
> All mail for smile.com is received by this company's ISP, and exim
> running on the company mail server, retrieves all mail from the ISP
> (ie. mail addressed to _anyone_@???).
>
> The company concerned also has 2 sales people remotely located who
> have e-mail addresses sales1@??? and sales2@??? and who
> subscribe to their own ISP.
>
> I can easily set up 2 e-mail addresses at the company's ISP for the
> sales people, so that the sales peoples e-mails are not picked up by
> exim running on the company's mail server. The sales people can then
> retrieve their e-mails separately.
>
> The problem is that people at the head office cannot send e-mails to
> sales1@??? and sales2@??? because exim treats such e-
> mails as local. ie. the exim configuration has an entry:
>
> local_domains = localhost:smile.com
>
> ..and sales1@??? and sales2@??? don't exist on the local
> mail server.
>
> Is there a way of configuring exim so that any e-mails addressed to
> sales1@??? and sales2@??? are not treated as local
> addresses but are sent as remote addresses?
>
> While I have considered this problem from a particular perspective, I
> am open to a completely different solution.
>
> Harold Zwier
> Melbourne
> Australia
>
>

Running all traffic through an ISP's MX as well as your own
usually brings more grief than value. Better to go all one way,
or all the other, not mixed. A few remote staff need never be an
issue, really.

Speaking as one who has never had a mail environment that was
NOT primarily composed of folks at diverse locations, the tried,
true, and simplest solution, since you have a domain and are
running an MX anyway, is to treat your (several) ISP(s)
primarily as 'connectivity' provider(s), [1] ignore their MX
system, and:

- Set up your Exim MX on a fixed-IP with proper DNS entries,
most especially a valid PTR record.

- Add the POP and/or IMAP daemon of your choice (we like Dovecot
or Courier, in that order. YMMV).

- Optionally add a Webmail interface - but have a care that it
is reasonably secure as well as 'user friendly' (i.e. look
askance at php-based daemons - most have a spotty vulnerability
record.).

- Advise one and all how to configure their MUA and/or Webmail
to login and authenticate.

Done.

Local, remote, or on-the-road, you woudl have a bog-standard
Exim environment, optioned/acl'ed as you see fit.

All you ordinarily need to do to insure staff have access from
anywhere they can get connectivity - even by slow dial-up - is
to make use of the 'submission' port (587) with TLS
authentication, not port 25.

IMAP(s) and POP3(s) ports are far less often blocked.

IF/AS/WHEN a traveler or remote office finds even 587 and/or the
POP/IMAP ports blocked by an ISP or diverted to their own MX,
(GSM/GPRS/3G mobile handsets...) one CAN open non-standard ports
on Exim - but a decent Webmail system is easier to manage as a
'fallback'.

Optionally: Install and require PEM certs on local workstations
and sales staff laptops if you want staff to NOT be able to use
the corporate system from off-site / out-of-hours /
borrowed/cyber-cafe/home PC's.

YMMV, but Inmarsat use aside, once connected to the 'net,
'remote' is only a diff of around w00 - 400 ms - often far less
- between nearly any points you are likely to work between.

IRC fiber-optic cable designers have seen to that.

Bill

[1] Check your ISP ToS. IF they prohibit your running an MX,
then you need to upgrade the service / choose another provider,
whether relaying OR running a standalone MX.