Re: [exim] Building virtual domain on multiple mail server

Page principale
Supprimer ce message
Répondre à ce message
Auteur: W B Hacker
Date:  
À: exim users
Sujet: Re: [exim] Building virtual domain on multiple mail server
Stephen Liu wrote:
> --- W B Hacker <wbh@???> wrote:
>


**trimmming extensively**

>>> - the most important goal is how to run multiple domains on one
>>> external IP. Each incoming mail can be delivered to its own mail
>>> server.
>
>> As to the above complex 'plan', one presumes your goal is to offer a
>> 'package' to each of many customers.
>


> This is only a test allowing multiple domains pointing to the same
> external IP. Each domain owner may have many users.
>


As said - easy for ONE Exim (or any of many MTA) to sort which
<domain>.<tld> is sought via a single external IP.

The difficulty of running *many* MTA has more to do with the nature of
TCP/IP and Domain Name Servers than with MTA's.

Ex:

- Your user community *should* authenticate on port 587 with TLS (and
require it) to send. TLS does not take kindly to being NAT'ed to more
than one possible internal IP.

- Your server *should* support TLS on port 25 (but not require it).
Likewise not especially happy with multiple redirection.

In either case, at the time of initial connection, you have ONLY the
IP's (and ports) involved.

Unless there is only ONE, you have no knowledge of WHICH <domain>.<tld>
the caller seeks until a later stage in the smtp process. By which time
the MTA is already chosen and committed.

>
> I made it successfully on the same guest of a Xen box (each guest can
> be considered as a physical PC) without problem. Users of each domain
> can logon the mail server on mail client, Evolution, to receive and
> send mails. All domains are pointing to the same external IP of the
> host. Each guest has its own hostname and local IP. On router all
> ports are forwarded to the local IP of the mail server, the guest. The
> host of the Xen box is only a simple desktop running Debian Etch. I
> use it for remote installing/configuring the guest. DNS, bind9, is
> installed on the mail server with /etc/resolv.conf removed
>


What you may or may not have found workable using a single external IP
and multiple internal IP in the setup you describe is not likely to hold
up in public-facing use.

- you CANNOT expect public-facing DNS to hold non-routable IP addresses

- your internal DNS would neither be visible, nor IF visible, 'welcome'
if holding non-routable IP's

- your callers CANNOT select an internal IP, even with a 'prefix' such
as xg1.example.com, xg2,example.com, xg(n).example.com, So LONG AS these
all point to the same external (routable) IP. Doubtful specifying a
different port would help, either, as smtp expects the listener to be on
port 25. And no other.

>
> All incoming mails of different domains are received by the mail server
> and delivered to their respective folders. Each domain has its own
> folder with subfolder alloted to each user. The server is now running
> nicely.
>


Or so you believe. But I submit it is doing so ONLY in an artificial
environment. Frankly, that is suspect as well - as there are other ways
you would seem to see the results reported.

Feel free to send me a direct message from each of two or more of your
separate Xen guests, see if my replies get to where the should do.

cc: this list, as there is a good chance MY server won't even talk to yours.

;-)

>
>> AFAICS, the Xen guest approach will need a unique *external* IP for
>> each


> I have no idea whether Xen guest can work on my planned way. If it is
> ONLY the problem of Xen I can run other virtualization packages,


It has nothing to do with the virtualizer. Everything to do with TCP/IP
smtp, and TLS.

>> IF all you can spare is ONE external IP, then you'll want to put all
>> customers on the same instance of Exim, which will keep them separate
>
>
> No problem. On the running mail server abovementioned all data of
> domains and their users are stored on the database, MySQL. But I
> haven't resolved how to route them to the respective mail servers, NOT
> on the same mail server. I wonder Exim can sort out my problem. Even
> if Exim can help me out I have to reserve on MTA for routing.


My point is that you do not NEED more than one mail server. Exim can
deliver to all manner of separate back-end storage.

But you'll have the same issues again w/r POP and/or IMAP.

So - either a unique IP per 'customer', or a fully shared resource that
is, in effect, 'partitioned' by <domain>.<tld> alone.

Which works superbly, securely, and well, BTW. Many folk host thousands
of them that way.

>> DNS:
>>
>> DNS *may* be run (also) on an MTA - but *should* be run on two or
>> more
>> OTHER boxes, and not all on the same backbone.
>
>
> If DNS only runs on ONE MTA how can other mail servers use it.


'Real' DNS is a public-facing service. Each <domain>.<tld> needs
entries in at least one that propagates globally, and 2 to 4 are
recommended.

> If
> installing DNS on all mail servers it is not my planning on this
> venture. Whether installing a separate DNS on a guest allowing other
> mail severs share it. If the arrangement is in this way then I'll add
> a DNS slave as well.
>


You need entries in a DNS 'somewhere'. The Registrar of the
<domain>.<tld> needs to know where, so the top-level root-servers can
point all-comers to it (root-servers do not want to hold specific records).

At this point - not to hurt your feelings - but I'm thinking you have
just enough marginal knowledge about how all this works to start getting
into trouble.

;-)

>
>> You will need AT LEAST your PTR RR in the IP-block holder's DNS (your
>
> Could you please explain in more detail. TIA


Not an Exim issue. Google and read how nameservers, DNS, IPV4 routing,
TCP/IP in general all work.

Try a 'host -v' on an IP or <domain>.<tld>

Try a 'dig any' .. likewise.

Your 'upstream' will have prepared forms available for you to submit to
get entries into their DNS. Thankfully, most don't resemble BIND zone
records directly, but are readable fill-in-the blanks format.

Download these for planning before you go much further.

HTH,

Bill