That's a simple e-mail server to e-mail server direct connection. There are a lot of things there that could go wrong. For example, if your e-mail server's IP address changes, you have to change it in DNS. That DNS entry can take hours, and sometimes days to propagate throughout the Internet. Also, networks can have little blips occasionally, or servers could be getting rebooted. If e-mail tries to deliver during that timeframe, it can't happen.

SMTP was engineered with this in mind. All e-mail servers will try to deliver the message, and if it cannot be sent, it will try again in a set amount of time. For most e-mail servers, that's a default setting of an hour or two before it tries again. So if you need an e-mail to go to a client or an employee and be acted on immediately, what happens if it gets delayed two hours? Did you just screw up a client job?

A Myriad of Problems Can Occur

Now, throw into the mix large environments that have multiple e-mail servers. Say there's a server that receives an e-mail at the edge of the network, then it has to route it internally through the customer network. I used to work for a large company whose parent company had thousands of servers, and multiple edge servers in clusters. Sometimes your e-mail going to the parent would get delivered to one of the edge servers and get stuck there, sometimes for days at a time. Once the admin figured it out, or the cluster got rebooted, the e-mail would finally break loose from the edge server and get delivered to the correct internal server. Would an e-mail that took two days to reach its destination possibly pose a problem? Yeah, I thought so.

Go to page: 1 2 

Printer Friendly Version