The Internet Message Access Protocol (IMAP) server lets an IMAP-compliant client mail program access remote message storage as if the storage were local. MultiNet's implementation is based on IMAP Version 4, Revision 1.
IMAP and the Post Office Protocol (POP3), described in the next section, operate differently. IMAP retains the message on the server, whereas POP3 retrieves the message and stores it "off-line" on the client, thereby deleting it from the mail server. IMAP does not delete the mail message and lets you access your mail from more than one client workstation at a time.
IMAP was designed to:
· Be fully compatible with Internet messaging standards, such as MIME.
· Allow message access and management from more than one computer.
· Allow access without relying on less efficient file access protocols.
· Provide support for "online," "offline," and "disconnected" access modes
· Support concurrent access to shared mailboxes.
· Eliminate the need for the client software to know about the server's file storage format.
The IMAP protocol includes operations for:
· Creating, deleting, and renaming mailboxes
· Checking for new messages
· Permanently removing messages
· Setting and clearing flags
· Server-based RFC-822 and MIME parsing and searching
· Selective fetching of message attributes, texts, and portions thereof, for efficiency
For other IMAP features and how they contrast with those of POP3, see either of these web sites:
http://www.imap.org/imap.vs.pop.brief.html
http://www.imap.org/imap.vs.pop.html
Problems arise when remote users log into systems using a login command procedure (SYS$LOGIN:SYLOGIN.COM or SYS$MANAGER:SYLOGIN.COM) that requires screen output. To inhibit this behavior, make sure the following lines are included at the top of all login command procedures:
$ VERIFY =
'F$VERIFY(0) ! Turn off verify without echoing
$ IF F$MODE() .EQS. "OTHER" THEN EXIT ! If a DETACHED process
(IMAP)...
$ IF VERIFY THEN SET VERIFY ! If a batch job, may want to turn
! verify back on.
In contrast to POP3, IMAP allows you to access server mail folders (message stores) other than INBOX. In MAIL, for example, if you create a NOTES folder, you can access mail in that folder. This NOTES folder can be in a mail file other than the default MAIL.MAI file. In fact, you can set a configuration parameter that determines the way mail folders are presented to the client so that you can use folders in these other mail files.
Your default mail directory includes a .IMAPRC file in which you can set certain configuration directives (described more fully in the IMAP Directives File section that follows). Among these directives is allow-subfolders. This directive specifies that folder names are comprised of a directory (optional), mail file, and folder. For example, the NOTES folder in MAIL.MAI is represented as mail/notes (as opposed to just notes if the directive were not set). This would distinguish it from another NOTES folder in the OLD.MAI mail file, for example, which would be named old/notes.
Each level beyond the second in this hierarchy represents a subdirectory of the default mail directory. For example, the NOTES folder in [.ARCHIVED]MAIL.MAI has the IMAP equivalent of archived/mail/notes.
Because of this folder syntax ambiguity, directory names, file names, and folders can overlap, such as the examples below.
|
This mail file... |
Containing this folder... |
Has this IMAP equivalent... |
|
MAIL.MAI |
NOTES |
mail/notes |
|
[.MAIL]NOTES.MAI |
STUFF |
mail/notes/stuff |
|
[.MAIL.NOTES]STUFF.MAI |
BOBS |
mail/notes/stuff/bobs |
Entries in the syntax can at different times be mail files, directories, subdirectories, or folders. Because of this overlap, the server must keep an internal representation of the hierarchy and mark what each level of the folder name means. This information is critical when renaming or deleting folders.
One restriction is that a first level folder (MAIL, for example) cannot be a message store, since it represents only a file and not a mail folder. INBOX, however, is a special case. INBOX is always INBOX, cannot be deleted or renamed (a rename moves messages to the renamed folder but does not delete INBOX), and never goes away. In IMAP, INBOX is mail/NEWMAIL by default, and is hidden to the user.
(Note that you can change the mail "in-box" from INBOX to another folder by defining the file-inbox-messages-to-folder directive in the .IMAPRC file. See the next section for details.)
You can also access mail files in your login directory (SYS$LOGIN) by prefixing the folder name with a tilde (~). The ~ folder is reserved and cannot be used by other folders.
Users can set certain preferences by creating a file in their default mail directory called .IMAPRC and including directives. The below table lists these directives along with their meanings. Each directive must be on its own line and in lowercase.
|
This directive... |
Does the following... |
|
set allow-child-folders |
Enables or disables the use of subfolders and the way that folders are presented to the client. By default, this value is false. If you want to set the value to be true, put this line in the .IMAPRC file: set allow-child-folders true. (See the previous section for details.) |
|
set autofile-messages-to-folder foldername |
Moves read messages from INBOX to the specified folder in the user's default mail file. By default, this option is disabled. |
|
set case-insensitive-folders |
Specifies that folder names
are case-insensitive. Otherwise, two folders with the same name but with
different cases could become inaccessible to the IMAP client. Newly created
folders are created in uppercase on the server. By default, this value is false.
If you want to set the value to be true, put this line in the .IMAPRC file: set case-insensitive-folders true |
|
set do-purge-reclaim |
Enables or disables purge-reclaim operations upon closing a folder. By default, this value is true. |
|
set folder-timer delta_time |
Specifies the frequency the IMAP server will check for externally created folders. By default, this value is 00:02:00 (2 minutes). |
|
set inbox-folder foldername |
Maps INBOX to the specified folder in the user's default mail file. By default, this value is NEWMAIL. |
|
set newmail-timer delta_time |
Specifies the frequency the IMAP server will check folders for new messages. (Note that checking for new mail is time consuming for large folders.) By default, this value is 00:00:30 (30 seconds). |
These options are valid in the global IMAPD.CONF file (MULTINET:IMAPD.CONF) as shown in the below table:
|
This directive... |
Does the following... |
|
set decnet-address nodename namespace domainname |
Maps the specified decnet nodename and/or namespace to a given domain name. Use " " to represent either a blank nodename or namespace. Multiple entries are allowed. By default, this option is disabled. Example:
set decnet-address knob " " door.com. |
|
set enable-full-cache |
Enables or disables full message caching. By default, this value is false. |
|
set max-ping-count integer |
Specifies, in number of messages, the threshold at which the server will no longer attempt to check for new messages. By default, this value is 20000. |
|
set smtp-transport-prefix string |
Specifies the SMTP transport prefix. By default, this value is SMTP. If you want to change it to MX, put this line in the IMAPD.CONF:
|
|
set trailing-header-marker string |
Specifies a text string used to indicate the start of RFC822 message headers if the system does not place them at the start of the message. By default, this option is disabled. |
The IMAP server includes files created in the user's mail directory where it maintains state information, as shown in the following table.
|
This file... |
Stores... |
|
.MAILBOXLIST |
Folders to which the user subscribes. |
|
.NEWMAILBOXES |
List of folders known to be empty. OpenVMS MAIL deletes folders once it deletes the last message, so that the server must "remember" these folders. |
|
mailfolder.foldernameuidvalidity |
For each folder, the UIDs for all the messages. The file name is composed of the folder name and its UIDVALIDITY code. For example: MAIL.NEWMAIL3B3200E6. In the example, the folder name is NEWMAIL and the UID validity code is 3B3200E6. |
The following IMAP logicals are supported:
By default, an informing message of This message cannot be retrieved is sent to the user when the processing message is too big. You can use this logical to define a different informing message. For example, if you define the logical like this:
$ define/sys/exe MULTINET_IMAPD_MESSAGE_ONE "Your mail is too big to be processed"
The message seen by the user is:
Your mail is too big to be processed.
If the defined logical string starts with @, the rest of the string defines a text file that holds the text. The maximum file size of the informing message is 255 bytes. For example, if you define the logical like this:
$ define/sys/exe MULTINET_IMAPD_MESSAGE_ONE "@MULTINET:IMAPD_MSG_ONE.TXT"
and edit the file MULTINET:IMAPD_MSG_ONE.TXT to be:
The size of this message is too big for the IMAP server to
process. Most likely it has a big attachment file. Contact the sender to
arrange re-transmission by other means such as FTP.
-System Manager.
The text message from the System Manager is seen by the user when the processing message cannot be retrieved.
There could be times when an oversized mail file prevents the mail system from working. This oversized mail file could also slow down other processes on the system. If such a case happens, use this logical to limit the size of the mail that IMAP processes.
When a mail file size reaches the limit defined by this logical, IMAP does not process it and sends a message to the user. Use the following metrics to define this logical: "S" (40K records), "M" (120K records), or "L" (240K records).
Note! Because VMS uses records to define the mail size and a record could have as few as 1 byte to as many as 255 bytes, the size limit defined by the logical does not reflect the actual mail size in bytes. For example:
$ define/sys/exe MULTINET_IMAPD_MESSAGE_SIZE_LIMIT "M"
A mail with a 5MB attachment file could reach the limit. But another mail with a 6MB attachment file could pass the limit.
|
Note: If the logical is not defined, the mail size limit is actually the current VMS Page file limit quota (PGFLQUO) of the IMAP process.
|
This logical enables additional logging for debugging purposes. Output is written to the file MULTINET:IMAP_SERVER.LOG. By default, this logical is unassigned. IMAP events normally are logged to SYSLOG.
This logical updates the last non-interactive login field in this SYSUAF for each IMAP login.
The MultiNet Post Office Protocol version 2 (POP2) and version 3 (POP3) servers allow a remote user to access mail stored in VMS MAIL files from POP2 and POP3 mail clients. The POP2 protocol is documented in RFC-937, "Post Office Protocol: Version 2," and POP3 is documented in RFC-1460, "Post Office Protocol: Version 3."
The remote user must have a valid account on the OpenVMS host and mail must be delivered into the VMS MAIL files associated with the account. A user specifies a user name and password when VMS MAIL is accessed from a POP2 or POP3 client.
The POP3 server accepts Kerberos V4 authentication in place of user name and password authentication. The current release of the Eudora mail client supports this method of authentication. The POP3 server allows cross-realm Kerberos V4 authentication when the logical name MULTINET_POP3_ENABLE_CROSS_REALM_AUTHENTICATION is defined.
The POP3 server waits indefinitely for input from POP3 clients. A logical is definable so you can specify the amount of time the POP3 server should wait for input before closing the connection. The logical is MULTINET_POP3_INPUT_WAIT x, where x is a normal VMS time string.
The POP3 server supports Unique Identifier Lists (via the UIDL command) for improved operation of Eudora clients.
The current release of the MultiNet POP3 server does not support the APOP authentication mechanism. The user name and password are validated by LOGINOUT, and a server process is created on the OpenVMS host. The server process invokes both the system-wide login command procedure (SYS$MANAGER:SYLOGIN.COM) and the user's LOGIN.COM before the POP server image is run. A log file is created in the user's login directory detailing the transactions between the client and the OpenVMS system; with POP2 this log file is called POP2_SERVER.LOG with POP3, it is called POP3_SERVER.LOG.
You can define the logical names described in this section to provide additional functionality to POP2 and POP3. These logicals, which affect several aspects of mail operation, can be defined either system-wide or for individual users.
|
Note: The default value for all of these logicals is 0 (all bits disabled).
|
You can use these logicals for either POP2 or POP3. In using the logicals, substitute either 2 (for POP2) or 3 (for POP3) for the x in the logical name.
MULTINET_POP3_UPDATE_LOGIN_TIME
When defined /SYSTEM, this causes the LAST NONINTERACTIVE DATE/TIME field in SYSAUF to be updated with the time the POP3 session was started. Note that this logical applies to POP3 sessions only.
This logical specifies functions as decimal values that are interpreted as described in the following table. To define more than one function, add the decimal values together; for an example, see the Defining the Logicals System-Wide section.
|
Value |
Effect |
|
|
1 |
Read only messages marked as new from the NEWMAIL folder. The default is to read all messages in this folder. If MULTINET_POPx_SOURCE_FOLDER is defined, this flag is ignored. |
|
|
2 |
Move messages from the NEWMAIL folder to the MAIL folder after they are read. If MULTINET_POPx_DEST_FOLDER is defined, this flag is ignored. |
|
|
4 |
Release the POP client before the VMS mailbox is actually closed; that is, cause a quick close. VMS MAIL can take several minutes to reclaim large amounts of deleted message space. The server replies to the client with a success, closes the connection, releases the client, and closes the mailbox. Any errors that result from closing the mailbox when this flag is enabled are lost. |
|
|
16 |
Remove the "NODE::" portion of the "From:" address. The MultiNet POP server creates RFC-822 headers from VMS headers before sending the message to the POP client. If the mail message was received via SMTP, SMTP headers are used.
When NODE is the same as the OpenVMS logical name SYS$NODE, the "NODE::" portion of the address is removed; otherwise, this portion of the address is retained.
For example: · For a local node WHITEFANG in which a message originates via DECnet from a remote OpenVMS host, the "From:" line is WHARFIN::HOLMES. · After conversion to RFC-822 conventions, the line is "WHARFIN::HOLMES"@WHITEFANG.EXAMPLE.COM. · Because some POP clients cannot reply to this address, the bit value represented by 16 should be enabled. When enabled, the "From:" line becomes HOLMES@EXAMPLE.COM.
|
|
|
32 |
Deleted messages are saved into the folder specified by MULTINET_POPX_DEST_FOLDER. Otherwise, when a message is deleted, it is removed completely. |
|
|
64 |
POP builds headers from the OpenVMS Mail "From" statement. Specify this flag when your mailer has been configured to not insert the SMTP headers as the first lines of text in the message.
The only time you should use this value in the MULTINET_POP3_FLAGS logical name is when you want to construct ad hoc SMTP headers (that is, when your SMTP agent is configured to place the real headers at the bottom of the message). |
|
|
128 |
The mail box is compressed, but all versions of MAIL.OLD in the MAIL directory are deleted. |
The MULTINET_POPx_DEST_FOLDER logical specifies the folder containing messages that have been read.
The MULTINET_POPx_SOURCE_FOLDER logical specifies the folder from which to read messages. The default folder name is NEWMAIL.
By default, the POP2 and POP3 servers look for mail in the NEWMAIL folder of the user's OpenVMS MAIL files. This default may be overridden by defining the logical names MULTINET_POPx_SOURCE_FOLDER and MULTINET_POPx_DEST_FOLDER in the file SYS$LOGIN:LOGIN.COM. For example, if a POP3 user wants to access mail stored in the MAIL folder by default, place the following command in LOGIN.COM:
$ DEFINE MULTINET_POP3_SOURCE_FOLDER "MAIL"
|
Note: OpenVMS MAIL folder names are case-insensitive.
|
When a mail message is accessed by POP2 or POP3, it remains in its original folder until the POP client deletes it. This happens even if the mail is being accessed from the user's NEWMAIL folder. Users may, however, define the logical name MULTINET_POPx_FLAGS, using the value 2, in their LOGIN.COM files to alter this behavior. If MULTINET_POPx_FLAGS is set to 2, mail messages are placed in a user's MAIL folder. This occurs after they are read via POP from the NEWMAIL folder, if the POP client does not delete the messages after it reads them.
This behavior is the same as with OpenVMS MAIL. For example, if a POP2 user wants mail read from the NEWMAIL folder placed in the MAIL folder after being read, add this command to LOGIN.COM:
$ DEFINE MULTINET_POP2_FLAGS "2"
Again, the user must also configure the POP2 client so messages are not deleted after they are read. If the client deletes a message, it is not saved in either the MAIL or NEWMAIL folder on the OpenVMS server.
All POP logical names can be defined system-wide for all users, as shown in the following example:
$ DEFINE /SYSTEM /EXECUTIVE MULTINET_POP3_FLAGS "7"
This example sets the flags parameter so that:
· All users only read messages from the NEWMAIL folder that are marked as new.
· Messages are moved from the NEWMAIL folder to the MAIL folder after they are read.
· The POP client is released quickly at the end of the mail session.