by Bryon D Beilman
I am a firm believer in simplicity whenever possible and that environments that are overly complex are those that have a greater chance of experiencing some type of failure. When one giant company buys another , how do you avoid complexity? Another way to think about it is; after all these various mergers, what happens in the background to provide you with the original service of the company?
Let's look at a simple example.
I was debugging an email problem for someone who said that mail to a certain someone was being rejected. The recipient email was @sbcglobal.net. Since this issue was recent and the company had recently switched Internet providers, I suspected DNS or IP spam filters were keeping the email from flowing.
Doing a DNS lookup to see who the MX server was (or the server who receives mail for sbcglobal.net) , I see that the DNS servers are someserver.swbell.net .
I also found the the 9 mail servers receiving mail for sbcglobal.net were servers1-9. prodigy.net. Ok, so I think back to the time that perhaps sbcglobal merged with prodigy.
Next I connect to the SMTP port of the mail server to do some testing. After entering my from address, as expected, it tells me that the IP address that I am coming from is on a DNS spam list and to get off the last , go to http://att.net/blocks web address and request to be removed from the list.
So now we have sbcglobal.net, swbell.net , prodigy.net and att.net.
I submitted the form and received an email from bellsouth saying that my request would be processed in 24 hours. Bellsouth? A baby Bell I hadn't heard about in a while (being from New England).
so, sbcglobal, swbell, prodigy, att & bellsouth all for one request. (A simple request at that)
Perhaps it doesn't make sense to collapse all of the infrastructure into one domain and it may make sense to utilize the larger IP space and distributed servers of the various merged companies. Any time someone thinks that merging services will simplify operations, take my brief experiment into account.