This chapter is quite different from the rest of this document. Here we build a foundation for understanding messaging, instead of focusing on how ZMailer behaves.
This chapter may feel a bit theoretical and abstract, being detached from practical life.
In reality, however, experience shows that most problems with messaging are a result of not understanding the underlying messaging model, or of not respecting said model.
The terminology used here may seem a bit X.400 oriented. It is, because folks from what was then known as CCITT (now known as ITU-T) adapted the model originally developed by IFIP. Of course, CCITT added a lot of things of its own invention (like ADMDs and PRMDs), that we don't need to bother ourselves with.
Although the terminology comes from X.400, it is in no way restricted to it. Our presentation here is a generic messaging presentation not restricted to any type of protocol.
Messaging, as the name says, is all about exchanging messages, short (or sometimes long) pieces of information. Messaging is always directional (which means that there is always a sender and one or more recipients), targeted (the list of recipients is fixed) and store-and-forward based.
There are a few messaging-like applications in which the message is broadcast to a wide, unspecified audience. A prime example of this latter application is Usenet News. News is not messaging, as it is not targeted.
So what about mailing lists that are linked to News, are they messaging or not? As long as the message is transported as a mail message, it is messaging. One of the recipients of the message may well be a Usenet News newsgroup. Similarly, a sender of a message might be the News system, or the author who initiated the submission by using News. Messaging is not necessarily interpersonal.
It is also quite normal for different applications to communicate by using messaging methods. A prime example of this would be EDI traffic. It is clearly messaging, but not interpersonal.
In addition to users, the basic building blocks of messaging are User Agents (UAs) and Message Transfer Agents (MTAs). User agents are the interface through which a human user interacts with the messaging system. On non-interpersonal messaging user agents may be built directly into applications. MTAs are used to transport messages from one computer system to another. An example of a good MTA is ZMailer. Access Units (AUs) can be used for accessing telematic services, for example telefax. Message Stores (MSs) can be used between MTAs and UAs. They are used for storing messages before and while UAs are used to access and manipulate them. Gateways (GWs) are used in between two different types of messaging systems, for example between SMTP and X.400 mail. Gateways are conceptually made of two MTAs and a UA that interconnects them.
There are two more acronyms worth looking at in the messaging model, namely MTS (Message Transport System) and MHS (Message Handling System). MTS is the collection of MTAs (and GWs), while MHS includes MTS and UA functionality (UAs, MSs and AUs).
A graphical example of the messaging model is shown in figure Figure 1-1. It shows the relationships between different elements of the model.
As can be seen, a user may use more than one UA, and a UA can be connected to more than one MTA.
Although it is important to understand the relationships between different entities in the messaging model, it is even more important to understand the nature of a message and the way UAs and MTAs deal with it.
A message consists of a body and headers. In case of messages with more than one bodypart (for example some MIME messages) the different body parts are all part of the outermost bodypart.
Figure 1-2. How a message looks normally.
Headers From: The Manager To: One Bright Employee CC: secretary Subject: Salary raise Date: 17 May 1997 Body Dear Employee, ... The Manager |
Figure 1-3. A possible, more complex message structure.
Headers Body Headers Body Headers Body Headers Body Headers Body |
As can be seen, there is always just one outermost body that contains all other bodyparts. In some cases, for example X.400 the protocol seems to violate this by leaving out the outermost bodypart. However, even on those cases we must assume, at the abstract level, that the outermost bodypart is there.
However, this is not all that there is to the structure of a message. When a message is in transit, being handled by MTAs it is put inside an envelope, just like a normal letter is inside an envelope while the postal service is carrying it. Just like the postal service is not permitted to look inside the envelope, neither are MTAs permitted to look inside. Whenever there is a need to look inside the envelope, it is always a UA function, and done on behalf, and on the authority of, a UA.
There are some violations of this. When using the SMTP protocol, the Received: lines are put in the headers by MTAs. This is bad engineering, but as the process of adding a new header line is fairly straightforward, it doesn't cause too much pain. In some cases MTAs, and especially the GWs modify the header even more, and sometimes they even mess with the body. This is a sure recipe for trouble.
Graphically, the way a message should be dealt with is shown in figure Figure 1-4.
The user creates the message with the help of a UA. How the interaction is arranged is a local matter. Once the message has been prepared, it is passed to a nearby MTA together with necessary envelope information and put into an envelope. The MTA puts its stamp on the envelope to show that it has received the message. The first MTA passes the message to the second MTA. The second MTA puts its stamp to the message and passes it to the third MTA, and so on. The final MTA passes the message to a UA, and the envelope is removed.
There are at least three ways to pass the message from an MTA to a UA. The message may be pushed to a (running) UA, a UA may pull it from an MTA, or an MTA may pass the message to an MS from which a UA will receive it at a convenient time.
The normal UNIX way of delivering mail (/usr/spool/mail/user) can be seen as any of the above three mechanisms, but should normally be seen as a UA pulling a message. The reason for this confusion is with the de-facto SMTP standard MTA, Sendmail.
Although Sendmail is in many ways a very clever piece of software, it is also the reason for many problems, as it has blurred the line between MTA and UA. Sendmail is clearly an MTA, but it also performs many of the UA level functions, like handling of ``.forward'' files. This behaviour has become the de-facto standard way for UNIX MTAs to behave, making it necessary for any MTA, including ZMailer, to behave the same way.
As MTAs only deal with envelopes, all routing and delivery decisions have to be based on information available on the envelope. It follows from this that the envelope and headers may contain conflicting information. This is normal, and is not a cause for worry.
MTAs may, and often do modify addresses present in the envelope. This might include changing addresses to a format more suitable for mail delivery and alias expansion.
It is important to make a distinction between aliasing and forwarding mail. Aliasing is an MTA function, in which an MTA effectively knows that to reach a seemingly local user, mail should be sent to a different address. To accomplish this, the MTA changes the recipient information on the envelope. Forwarding is a UA function. When forwarding, the mail message is received by the original, intended recipient, and re-sent to another address. Although forwarding is a UA function, it doesn't have to result in a change to body or headers, but on the envelope, both sender and recipient should be changed. Sendmail bluntly violates this, and makes most other MTAs violate it as well.
Most mailing lists today are just alias expansions, on which one recipient address on the envelope is replaced with multiple addresses. In many cases this is a reasonable approach. However, all major mailing lists should be set up as a UA function. This involves changing not only the recipient address but also the sender address in the envelope. In this way, undeliverable messages are sent to the owner of the list, who can deal with the problem, and not to the sender of the message, who can do nothing to remedy the situation. (The ZMailer has some builtin facilities for this, see about Mailing Lists… on section Section 13.2.2.)
Error messages must be sent to the envelope sender address, as this is a MTA function. If a header like ``Errors-to:'' is being used, it implies that envelope sender should be sent to the one in the ``Errors-to:'' header.
Replies to messages should be sent to header addresses, because replying is a UA function.