|
|
The online FAQ database contains hundreds of answers to frequently asked questions, articles on using our
web server applications and other related technologies, and resolutions to common problems. If you are seeing
an error message, be sure to try searching on the error message or error number that you are seeing.
| | | | | | | | |
|
|
All of the XCENT web server applications can send email to users using a variety of Email Components. All of these components use SMTP (Simple Mail Transfer Protocol) to send email messages across the internet. SMTP is by far the most commonly used email delivery system in the world. SMTP has many idiosyncrasies and flaws, but it has proven to be a real workhorse and is pretty efficient at what it does. Today it would be difficult to find anyone who has used the internet to send email that has not used SMTP to do it. Luckily for end users, they really do not need to know too much about it. They only need to know their friend or associates SMTP email address. Actually, since SMTP is so ubiquitous, end users do not even typically refer to it, or know about it. Basically this means that nearly everyone assumes email over the internet is via SMTP.
However, there are some idiosyncrasies and problems with SMTP that are important to realize when you are running active web server applications or sending a volume of email. Not that there is much a site operator can do about it, but it is certainly beneficial to understand and comprehend such "facts of life". One is that SMTP really does not have a way to guarantee delivery of a message. It is possible, and it certainly does happen, that an email may sometimes not actually ever make it to the Inbox of the person you sent it to. SMTP is robust enough in and of itself that this is not usually a problem that happens often. It is usually caused by other external problems. The most common way this happens is hardware failure. SMTP basically assigns responsibility of handling the email message to the machine (server) that has most recently been forwarded a copy of the message. When an email message is sent, it is handed off from one machine to another until it reaches its destination. This is exactly analogous to the way a physical piece of mail is handled in the real world. When you hand your letter to the postman, he passes it on to the next responsible party until the mail is finally delivered to its recipient's mailbox. The same is true when you send an email message. The originating machine sends an email message to a second machine. The first machine hands all responsibility for delivering the message over to the second machine as soon as the second machine confirms it has accepted the email message. The first machine then promptly forgets that it has even sent the message (it erases it). The responsibility for delivering the message to its final destination is now solely up to the second machine. The second machine now figures out where it must now forward the email message to in order to move it closer to its destination. Once it does that, it repeats the processing of sending the message and handing off the responsibility of delivering it to the next machine in the line. This process continues until the message is actually handed over to the machine that contains the recipient's mailbox. If the machine actually has the recipient's mailbox, then the message is deposited in the end users mailbox until the end user retrieves it with an email client. So, a single piece of email bounces from machine to machine until it ultimately finds its destination. At a minimum, this usually means at least two mail servers are involved in getting it from the sender to the recipient. However, today there can be many more machines in between the sender and recipient and a piece of email must travel through several mail servers to reach its destination. It is not unusual for a message to have to move through at least three, maybe up to six or more servers before it reaches its destination. If during the course of the message moving from server to server, a catastrophic failure occurs on the server that happens to currently have your message, the message could be lost. This can happen when a machine fails completely and must be replaced (many messages could be lost); or because of software failures or other maintenance mistakes.
Another issue to be aware of with delivery of email is the speed of delivery. Many people assume that email delivery is nearly instantaneous. Meaning that the moment you hit the Send button on an email you have crafted, it will appear in the Inbox of the recipient within a second or two. While this certainly can happen, there is no guarantee in how long a message will take to be delivered. And in actuality, the message can sometimes take quite a significant amount of time to reach the end user's inbox. Most mail servers operate in a manner like we are going to describe here. When an email message is handed over to a server, the server immediately puts the message in a mail queue. It does not directly decide what to do with the message at the moment it receives it. Messages are dropped into the queue as fast as they are received. On either a scheduled basis, or when the mail server decides that it should look at the messages in it mail queue, it will start examining each individual message and then deciding what to do with it. It looks at an individual message and based on the addressing information in the message, it decides if it needs to be dropped into a local user's mailbox, or forwarded along to another mail server. If the mail server is receiving allot of email at once, many messages can build up waiting in the queue until the mail server can get around to examining each message individually. Messages usually are processed in the order in which they were received, but there is no guarantee of this. So, a very busy mail server may hang onto an individual message for quite some time. It's not unusual for messages to be delayed by several minutes or longer on very busy mail servers. If a mail server is very overwhelmed with a large load of queued mail, an individual message could sit in queue for hours. For example, say a particular message is headed to a user email address on the EXAMPLE.COM network. If EXAMPLE.COM is a very large network, the EXAMPLE.COM mail servers can get quite busy. Or say someone with an email address on the EXAMPLE.COM network just advertised on a television show and had 100,000 people send a message to an account on the EXAMPLE.COM network, then the mail server on that network might receive about 100,000 email messages at close to the same time. These messages go into the mail queue and wait to be processed by the mail server. Say the mail server can process 100 messages per second; then it would take the mail server 1000 seconds to process all the incoming email, or a bit over 16 minutes just for the mail server to decide what to do with the messages. If the messages needed to be sent on to another server, then they are added to an outgoing mail queue where they wait again while the mail server tries to send them off to the next mail server in line. If your mailbox was on this server, then your incoming email at that moment would be delayed by at least 16 minutes while the server worked it's way through all that incoming email. If your message just had to pass through that server, it would just be sitting around there for at least that long before it was even scheduled to be passed along to the next server.
Once it is determined that a message needs to be passed through the mail server, the mail server schedules it to go out along to the next server by putting it in it's outgoing mail queue. The process of sending the message to the next server is typically slower than the process of the server just processing the incoming mail. This is because the mail server again looks at each message and then tries to contact the next mail server that the message should be forwarded to. If the next mail server is too busy and cannot accept the message right now, or if it is temporarily offline (maintenance or network problem), then the mail will be rescheduled to be sent again later. Since it is unknown when would be a good time to try to resend the message, the message will probably not be attempted to be sent again for a considerable amount of time. Fifteen minutes or more is not uncommon. On very congested networks, a message can be delayed a couple of times like this before it is passed along successfully. When something like that occurs, sometimes messages are moved out of the queue in a different order than they were received. If two messages were sent one before the other, this can cause the messages to arrive at the recipient(s) in an order that differs from the order in which they were originally sent.
Today, it is also common for many organizations and networks to use email content filtering and virus scanning gateways on their email servers. These types of systems can also slow the progress of email through the mail server as messages are screened. If the messages contain attachments of certain types, sometimes a person is actually responsible for screening them before the message is allowed to be passed on. Of course that can severely slow down the speed in which a message is delivered. There are many things that can slow the progress of email through networks and sometimes even prevent it from happening at all.
For site operators running web server applications, the good news is that SMTP mail is usually so efficient that most people are not even aware of all this. Usually email is delivered quickly and quietly to the end user. However, just because it is working perfectly right now, does not mean your site will be immune to network problems or congestion along the way that will prevent the smooth operation of email for all of your site users. Since SMTP has no method for guaranteeing or insuring delivery to a recipient, a web server application cannot know if the end user ever receives the message or not. As we saw above, once a server hands off the message to the next SMTP server, the responsibility for delivering the message has passed onto the other machine. Once a web server application generates a message and sends it off to your SMTP server, the web server application has given up all responsibility for getting the message to the user. The responsibility for getting it there lies in all the mail servers in between your web server and the end user. And even when messages are instantly generated by the web server, they do not instantly appear in the end user's Inbox. They must first move though all the mail servers in between your web server and the end user's Inbox. As we saw above, there can be many reasons for delays and such things are not usually under any one person's or organization's control. The internet and its related technologies, such as SMTP, are a cooperative effort by all the networks and machines in between any two points. Sometimes it doesn't work 100% smoothly, but usually it works great and with such speed that cannot be matched in the physical world.
|
| | | | |
|
