From the user's point of view, sending a message to someone on another computer is not very different from sending a message to someone on your own computer. If your site is running the extra software needed for multi-machine mail, you use the MAIL8 system in exactly the same way with exactly the same commands. The major difference is that time-lags are inserted at several points in the delivery and acknowledgment process.
For example, if you misspell the name of a recipient on your own machine, you are informed immediately. If you misspell the name of a recipient on another machine, it may take some time before the message is rejected at the destination machine and an appropriate error notice is sent back to you. Nevertheless, MAIL8 aims to be 100% reliable, in the sense that every message is delivered or else you receive notice telling why a message could not be delivered.
The sections that follow discuss the ways in which remote mailing differs from local mailing. We begin with factors that affects users directly, then go on to the internal mechanisms of inter-machine MAIL8.
Addresses for users at remote sites are specified in the form
userid@site.domain
in this version of MAIL8. Later versions of MAIL8 may support more sophisticated address formats, in accordance with the RFC822 standard.
Userid groups may contain the userids of both local and remote users. For example,
rhood
mmarian
ljohn
ftuck@sherwood.forest
could be the contents of a userid group that has three local users and one remote one.
A simple remote address only contains alphabetic characters, digits, and the underscore. If a remote address contains other characters, the entire address should be enclosed in single or double quotes, as in
mail to "j;smith@mach$$.*dom"
Quotes are not needed if the first character of an address is a slash (/) character.
Your alias file may define aliases for remote users in the same way that it defines aliases for people on your own machine. For example,
joe jsmith@remote.domain
could be a line in the alias file defining an alias for a remote user.
It is also possible to define aliases for remote sites. A line of the form
*@alias sitename.domain
says that the given alias refers to the specified site. For example,
*@sw sherwood.forest
indicates that sw is an alias for the sherwood.forest site. MAIL8 therefore expands
rhood@sw
into
rhood@sherwood.forest
A line of the form
*@*.alias domain
associates an alias with a domain. For example,
*@*.h HN
would change a name like
joe@remote.h
to
joe@remote.HN
For site and domain aliases, MAIL8 does not distinguish between upper and lowercase. For example, if an alias is defined as
*@*.h HN
you can use the alias as either ".h" or ".H". This is different from userid aliases: when you use an alias in place of a userid, the alias you give must exactly match the alias given in the alias file, including the case of letters.
With user aliases, you may have one alias standing for a group of users. You cannot do this with site and domain aliases -- a site alias may only stand for one site, and a domain alias may only stand for one domain.
In any address, only the first piece and the last piece of the address are examined and replaced if they are aliases. For example, in
name@site.domain
only the name and domain are examined and replaced if they are aliases. In
name@site
both the name and site are examined and replaced. In
name@site.domain1.domain2.domain3
only the name and domain3 are examined and replaced. The unexamined parts of the domain will stay as they are, even if they happen to match alias names. Therefore, you have to be careful if you specify a domain alias in an actual address.
Aliases may take the form
user@site
For example, you might have the following set of definitions.
joe jsmith@east.hn
joe@west jjones@west.hn
joe@north jbrown@north.hn
These are three different aliases for three different users. If you just send mail to joe, MAIL8 uses the first alias. If you send mail to joe@west or joe@north, MAIL8 uses the appropriate aliases. If you send mail to joe@south (which isn't a defined alias), MAIL8 tries to send the message to the user joe at the machine south; joe is not treated as an alias.
You should be careful that domain and site aliases do not map into null strings (i.e. strings that contain no characters). If you create such an alias, you may receive confusing diagnostic messages. After creating any alias, it's a good idea to enter MAIL8 and issue the Alias command to make sure that the alias really does map into the name you want.
You may use the Redirect option to redirect your mail to a remote userid. In this case, however, MAIL8 has no way to detect loops that occur if User 1 on Machine A redirects his mail to User 2 on Machine B, and User 2 on B redirects her mail to User 1 on A.
If you MODify an Outbound message, the change may or may not be meaningful. As described later, Outbound messages for a particular remote machine are collected and sent to that machine according to a schedule set by your site. If you MODify your Outbound message before it is sent off to the other machine, the modified message is the one that reaches the remote site. However, if the message is sent out before you MODify the message, the unmodified message goes to the remote site and the remote MAIL8 package does whatever is appropriate with the unmodified form of the message.
Different sites have different schedules for when mail is gathered and sent off to remote machines. Ask your system administrator for details.
The command
remail +Transit
resends an Outbound message to any recipients on remote systems. The message is not sent to recipients on your own system. Because of delays between machines, the above command may send a second copy of a message to a recipient who has already read the original.
With multi-system mail, Delete +Outbound still tries to retract messages sent to remote recipients. However, it may not succeed. You will not be told whether or not Delete was successful.
With multi-machine mail, the Summary command may indicate that an Outbound message is "In Transit". This means that the message has been picked up for transmission to a remote site, but your MAIL8 system has not yet received confirmation that the message was transmitted to the site successfully.
The Summary command may also indicate that an Outbound message is
On site: user@site.domain on date
This means that the Outbound message has successfully reached its destination site and is waiting to be read. Thus a message changes from "In Transit" to "On Site" once MAIL8 can ascertain that the message successfully reached the remote site. When the message is finally read, itdisappears from your Outbound drawer (if it was not Registered).
The CONFiguration command may take an argument that states the beginning of the name of a site or a domain, as in
configuration wat
This displays configuration information related to any site or domain whose name begins with "wat". Specifying a string in this way automatically implies the +Verbose option.
This section looks at a number of commands and command options which are only of interest to site administrators.
The commands
Summary +ACCept
Summary +CANcel
can summarize the Accept and Cancel messages in network linkboxes. The commands
Delete +ACCept
Delete +CANcel
can delete Accept and Cancel messages in network linkboxes.
In a network linkbox,
Summary +Outbound
displays the From header line instead of the To line.
Site administrators may use the EXPIRE command to clean out network linkboxes. If EXPIRE deletes an Outbound message from a linkbox, it notifies the original sender that the message expired.
Some sites have established interfaces between MAIL8 and other electronic mail packages. However, other packages do not have the same system of positive acknowledgment that MAIL8 has. For this reason, you will not receive reliable confirmation of delivery or non-delivery once the message is passed to other mail software.
If a message coming from a remote system does not represent times and dates in MAIL8's format, MAIL8 uses the first 20 characters of the date/time string.
You do not need to read the material in this section to use inter-machine MAIL8. However, it is useful if you want to understand how it all works.
Your system has the equivalent of a mailbox file for every remote machine with which you can exchange messages directly. These mailbox files are like an ordinary user's mailbox. When you send a message to someone on a remote machine, the usual message is created in your Outbound drawer, and an unread message notification is put in the Unread drawer of the mailbox that is associated with the remote machine.
Every so often, the system runs a program that checks the Unread drawer of the mailbox associated with the remote machine. This program is called a server. The server copies all the messages associated with these Unread notifications into data files, then invokes a data transfer mechanism that copies all these messages to files on the correct remote machine.
Just as your system has a mailbox associated with the remote machine, the remote machine has a mailbox associated with your system. Every now and then, the remote machine runs a server that checks to see if files of messages have arrived from your system. If there are such files, the server adds the new messages to the Outbound drawer of the mailbox associated with your system. The server then delivers all these Outbound messages.
From the point of view of MAIL8 on the remote machine, your message originated in the Outbound drawer of the mailbox associated with your system. When the intended recipient reads the message, the usual thing happens: the Outbound message is deleted from the mailbox.
The next time the server on the remote machine wakes up, it sees that your message has been read. The server creates a file with an entry that means "This message has been read by this recipient" and invokes the file transfer mechanism to pass this file back to your system.
When your system's server is activated, it looks for the file sent by the remote machine. The server sees that your message has been read, so the server effectively "reads" the Unread message that is still in the mailbox associated with the remote machine.
When the normal MAIL8 system sees that your message has been read, it marks your Outbound message appropriately and deletes it if all intended recipients have now read it.
As you can see, there is a great deal of passing information back and forth between the two machines. Even more of this goes on if the message you sent had to be read by more than one recipient, but the principle is much the same. The server on your system makes it look as if the mailbox associated with the remote machine is the actual recipient of the message. The server on the remote machine makes it look as if the mailbox associated with your system is the actual sender of the message.
On the remote machine, a copy of your message is stored in the Outbound drawer of the mailbox associated with your system. If you sent a huge message to the remote machine, it might be possible that you fill up this mailbox and cause other messages to be rejected. In addition, there is the question of who pays the charges associated with storing the message in the remote Outbound drawer.
To solve such problems, future versions of MAIL8 may not begin by transmitting large messages in their entirety. Instead, the servers may only send a small portion of your Outbound message. When this is finally delivered, MAIL8 will ask the recipient if he or she accepts transmission of the full message. If the recipient accepts transmission, the remote server will tell your server to go ahead and send the whole message. When the message finally arrives on the remote machine, the server copies it directly into the recipient's Saved drawer without going through the usual intermediate mailbox. In this way, the intermediate mailboxes will never have to hold really large messages.
Copyright © 1997, Thinkage Ltd.