6 replies to this topic

[+Xenosion]

So this is a topic that can fit under many forums be it hardware, server or technical support, etc. My question comes down to this: how do these large cloud services providers manage their back-end to automate and even segregate the services from each customer?

There are a couple examples of what I'm referring to the best of which is Microsoft's Office 365 or, more specifically, Hosted Exchange. I'm talking about everything from licensing to reverse DNS records. If I wanted to do something like this for my clients, I could have an Exchange server that accepts mail for many domains and I could create many users with specific email addresses manually assigned. This is entirely a manual process though. How do these large cloud services providers do this in an automated way? I would assume Microsoft would use a Microsoft product to accomplish this. Maybe they have created a custom system using APIs or something?

On the more technical side, if I were to have an Exchange server and do this, it would be behind one IP address and thus only one reverse DNS record could be made for a lookup back to it (right?). It's completely inefficient to have an exchange server for each person that signs up for Microsoft's Hosted Exchange. Another large setback to using one Exchange server is the originating server's responding FQDN. As far as I know, this can be only one domain and if someone were to look at the an emails message details, they could see that this person's email did not come from domainxyz.co but from another domain123.co as would all other customers on the same Exchange server.

Hopefully someone has insight on this!

[xendrome]

As a simple answer of "it just works don't worry about it" I would add in,

At a level of Microsoft or Google's services, you are talking custom written software to run all of this.

So they can program it exactly how they want it.

[+Xenosion]

xendrome, on 09 May 2012 - 17:17, said:

As a simple answer of "it just works don't worry about it" I would add in,

At a level of Microsoft or Google's services, you are talking custom written software to run all of this.

So they can program it exactly how they want it.

Which I would expect from Rackspace (another of these cloud providers) but I was hoping that Microsoft would be using their own product/tools to do this. I can understand though that to make this readily available creates direct competition.

I know that it just works and I'm fine with that. However there are some technical aspects such as reverse DNS records and FQDN responses that are fundamental workings of email technology, I don't think a custom software can make exceptions to how these things work.

[+BudMan]

accepting mail is different than sending mail. You don't need a PTR for accepting mail.. The only time a ptr is checked is the accepting server checking the server sending it mail - if no valid PTR then its most likely some fly by night mail server, etc.. and prob spam - so sure many major domains will not accept mail from such a server.

But this is not the case with having servers that accept mail for users.. They do not need ptr to match anything.

You can have a cluster of servers accepting mail on lots of different IPs, or even behind a load balancer accepting the connection on 1 IP and then sending on to email servers behind that to handle the getting of the mail and then once accepting it routing it to the mail server the mail box sits on for that user.

Take a look at your say gmail or yahoo.com headers for email sent to you.. It more than likely routes through a few servers on gmail or yahoo side.

example

Delivered-To: snipped@gmail.com
Received: by 10.60.141.201 with SMTP id rq9csp9608oeb;
Wed, 9 May 2012 10:23:08 -0700 (PDT)
Received: by 10.182.44.74 with SMTP id c10mr1164113obm.43.1336584188741;
Wed, 09 May 2012 10:23:08 -0700 (PDT)
Return-Path: <root@mail.adagioteas.com>
Received: from mail.adagio.com (mail.adagio.com. [67.192.109.186])
by mx.google.com with ESMTPS id fq1si187201obc.135.2012.05.09.10.23.08

see where mx.google.com got it from mail.adagio.com -- then it went through 2 private IPs in googles network before I got it.

This is routing internal to gmail system..

Same goes for the way back out -- you send email using gmail to say yahoo. You create the message on the server you connected too, its more than likely going to be routed through a few servers again before it gets to the actual sending server(s) that will send the mail to yahoo.

If you want to understand how an email message flows - just look at the headers, it will show you all the different email servers that message went through to get from where sent to your mailbox.

[+Xenosion]

Basically I am researching how I can duplicate these hosted Exchange solutions for my clients.Typically for my clients who have their own mail server, headers will read that the message originated from their domain/networks because of the send connector. If I host their mail, it will come from me. Is that unavoidable? Or am I being way to concerned about what the message headers say?

In an Exchange server that is hosting mail for many domains, what is the best way segregate the customers? Different databases? Could you create different send connectors for each domain and somehow only allow certain databases to send out with a connector? This would solve the outgoing mail headers having a strange originating domain. But can you have multiple PTRs going back to the same IP?

[+BudMan]

not sure why your hung up on PTR? so you want your sending server to match up with their forward domain?

So for example you have domainA.tld, domainB.tld, domainC.tld

And all being sent from same email server at 1.2.3.4, your concerned that when someone looks up 1.2.3.4 PTR it will reflect say mx.domainZ.tld?

There there is no way to have multiple PTR records for the same IP. Sure you can have mx.domainA.tld, mx.domainB.tld both point to the same IP.

I would not worry too much about the PTR, as long as its valid. So for example mx.domainZ.tld, while that server hosts mail for domainA, domainB, domainC, etc.. you don't even have to have the mx for domainA point to something domainA, it can point to mx.domainZ.tld just fine -- does not matter what the name of the server is accepting the mail for a specific domain.. Quite often it does not match.

example neowin.net mx points to google servers. Companies host their mail on other domains all the time, the name of the server that accepts mail for your domain does not have to be in the same domain.

Keep in mind that the sending server is not always the same name as the sending domain either. Just look through the headers of the email in your inbox

[+Xenosion]

BudMan, on 09 May 2012 - 22:03, said:

not sure why your hung up on PTR? so you want your sending server to match up with their forward domain?

So for example you have domainA.tld, domainB.tld, domainC.tld

And all being sent from same email server at 1.2.3.4, your concerned that when someone looks up 1.2.3.4 PTR it will reflect say mx.domainZ.tld?

That is exactly my concern. I would like it to be as seemingly segregated as possible. Do you think this is impossible when using one Exchange server? I think you answered that here:

BudMan, on 09 May 2012 - 22:03, said:

There there is no way to have multiple PTR records for the same IP. Sure you can have mx.domainA.tld, mx.domainB.tld both point to the same IP.

This is only one technicality that I'm hung up on. I am still curious how Exchange is best configured to manage multiple domains.