Background Details

Domain Names

Domain names are used to uniquely name each host on the Internet. A domain name has a number of parts separated by periods. Each label represents a level in the hierarchy. An example of a name is:
In this domain name the top-level label is edu, indicating it is at an educational institution, the second-level label is washington, indicating the University of Washington. cac is a specific department within the University of Washington, and olive is the host name. The top-level names are assigned by Internet organizations, and other names are assigned at the appropriate level. The Domain Name Service, DNS, is the distributed database used to look up these names.

Pine relies on domain names in multiple places. A domain name is embedded into the message-id line generated for each piece of email. A domain name is needed to contact an IMAP server to get access to remote INBOXes and folders. Most importantly, domain names are needed to construct the From: line of your outgoing messages so that people on the Internet will be able to get email back to you.

On UNIX systems, you can set the domain via the user-domain variable in the Pine configuration file, or rely on the file /etc/hosts which usually sets the name of the local host. While Pine can often deliver email without the domain name being properly configured, it is best to have this set correctly. Problems can usually be solved by adjusting the system's entry in the /etc/hosts file. The fully-qualified name should be listed before any abbreviations. olive
is preferred over olive

On PCs, the task of configuring the domain name is a bit different. Often times, PCs do not have domain names-they have IP addresses. IP addresses are the numbers which uniquely identify a computer on the network. The way you configure your IP address depends on the networking software which you use on the PC. You can refer to the documentation which came with your networking software or see the PC specific installation notes for help configuring the IP address with your network software.

With PCs, it is vital that users set the variable user-domain in the Pine configuration file (PINERC).

Details on configuring Pine with correct domain names can be found in the Domain Settings section of this document.

RFC 822 Compliance

Pine tries to adhere to RFC 822 a little more strongly than some other mailers and uses the "full name <address>" format rather than the older "address (full name)" format. The intent of the standard is that parentheses should only be for comments. Pine displays and generates the newer format, but will parse the old format and attempt to turn it into the new one.

As far as outgoing email is concerned, Pine fully-qualifies addresses whenever possible. They are even displayed in fully-qualified form on the terminal as the user composes a message. This makes addresses more clear and gives a hint to the user that the network extends beyond the local organization. Pine implements fully-qualified domain names by tacking on the local domain to all unqualified addresses which a user types in. Any address which does not contain an "@" is considered unqualified.

The newer format for addresses allows for spaces and special characters in the full name of an address. For this reason, commas are required to separate addresses. If any special characters as defined in RFC 822 appear in the full name, quotes are required around the address. Pine will insert the quotes automatically. The common cases where this happens are with periods after initials and parentheses.

Because Pine fully complies with RFC 822, it is sometimes difficult to use non-Internet address formats such as UUCP's host!user or DECNet's USER::HOST with Pine. People who run Pine on these systems have made local modifications to Pine or to the mail transport agent (e.g. sendmail) to make things work for them.

Pine expects dates to be in the standard RFC 822 format which is something like:

	[www, ] dd mmm yy hh:mm[:ss] [timezone] 
It will attempt to parse dates that are not in this format. When an unparsable date is encountered it is displayed as xxx xx when shown in the FOLDER INDEX screen.

SMTP and Sendmail

Pine is a user agent not a message transfer agent. In plain English, that means Pine does not know how to interact with other computers on the Internet to deliver or receive email. What Pine does know how to do is help users read, organize and create email. The "dirty work" of delivering and accepting email is handled by other programs.

All outgoing email is delivered to a mail transfer program or to an SMTP server. The most common mail transfer program is sendmail.

Pine 3.91 and earlier:
When Pine on a UNIX computer uses the local sendmail, it first writes the message to a temporary file in /tmp. Then Pine runs a shell in the background that runs sendmail on the temporary file and then removes it. This is done with a shell in the background so the user doesn't have to wait for sendmail to finish. By default, sendmail is invoked with the -t flag to cause it to read and parse the header to determine the recipients; the -oem flag to cause errors to be mailed back; and the -oi flag to ignore dots in incoming messages. Systems administrators can choose to configure Pine to use a different mail transfer program or even sendmail with different flags. See the section on UNIX Pine Compile-time Options for more details on this.

Pine can also operate as an SMTP client. SMTP stands for Simple Mail Transfer Protocol; it specifies the rules by which computers on the Internet pass email to one another. In this case, Pine passes outgoing email messages to a designated SMTP server instead of to a mail transfer program on the local machine. A program on the server then takes care of delivering the message. To make Pine operate as an SMTP client, the smtp-server variable must be set to the IP address or host name of the SMTP server within your organization. This variable accepts a comma separated list of servers, so you can specify multiple SMTP servers. PC-Pine only runs as an SMTP client.

Pine 3.92 and later:
The selection of which MTA to use depends on the settings of sendmail-path, smtp-server, and compile-time options. The first MTA specified in the following list is used:
  1. sendmail-path in /usr/local/lib/pine.conf.fixed
  2. smtp-server in /usr/local/pine.conf.fixed
  3. sendmail-path specified on the command line.
  4. smtp-server specified on the command line.
  5. sendmail-path in the user's .pinerc file.
  6. smtp-server in the user's .pinerc file.
  7. sendmail-path in /usr/local/lib/pine.conf
  8. smtp-server in /usr/local/pine.conf
  9. DF_SENDMAIL_PATH defined at compile time.
  10. SENDMAIL and SENDMAILFLAGS defined at compile time.

If the sendmail-path form is used, a child process is forked, and the specified command is executed with the message passed on standard input. Standard output is then passed back and displayed for the user. NOTE: The program MUST read the message to be posted on standard input, AND operate in the style of sendmail's "-t" option.

If an smtp-server is specified, a connection to the server is opened. If the message contains 8-bit text, ESMTP 8BITMIME negotiation is attempted. The message is then sent using SMTP commands.

If none of the above are set, the default sendmail program is invoked with the "-bs -odb -oem" flags, ESMTP negotiation is attempted, and the message is sent.

Internet Message Access Protocol (IMAP)

IMAP is a remote access protocol for message stores. Pine uses IMAP to get at messages and folders which reside on remote machines. With IMAP, all messages are kept on the server. An IMAP client (such as Pine) can request specific messages, headers, message structures, etc. The client can also issue commands which delete messages from folders on the server. IMAP's closest kin is POP, the Post Office Protocol, which works by transferring an entire mailbox to the client where all the mail is kept. For a comparison of IMAP and POP, see the paper "Comparing Two Approaches to Remote Mailbox Access: IMAP vs. POP" by Terry Gray. A more detailed exploration of message access may be found in the paper " Message Access Paradigms and Protocols." These papers may be found in the /mail directory of the anonymous FTP server at

IMAP Features:

IMAP2 is defined in RFC 1176. IMAP4rev1, the revision to IMAP2, is described in RFC 3501. Further information about IMAP may be obtained from the University of Washington's IMAP Information Center on the World Wide Web.

Pine 4.00 is an IMAP4rev1 client.

Multipurpose Internet Mail Extensions (MIME)

MIME is a way of encoding a multipart message structure into a standard Internet email message. The parts may be nested and may be of seven different types: Text, Audio, Image, Video, Message, Application and Multipart (nested). The MIME specification allows email programs such as Pine to reliably and simply exchange binary data (images, spreadsheets, etc.). MIME includes support for international character sets, tagging each part of a message with the character set it is written in, and providing 7-bit encoding of 8-bit character sets. It also provides a simple rich text format for marking text as bold, underlined, and so on. There is a mechanism for splitting messages into multiple parts and reassembling them at the receiving end.

The MIME standard was officially published in June of 1992 as RFC 1341 and subsequently revised in RFC 2045 when it became a full Internet Standard. Pine 3.0 was one of the first email programs to Implement MIME. Now, there are dozens of commercial and freely available MIME-capable email programs. In addition, MIME is being added to newsreaders so MIME messages can be posted and read in USENET newsgroups.

The MIME standard also includes support for non-ASCII text in message headers through the extensions described in RFC 1342 and subsequently revised in RFC 2047. Support for RFC 2047 was added in Pine 3.92.

An actual MIME message looks something like this:

Date: Tue, 12 Mar 1996 15:39:35 -0800 (PST)
From: David L Miller <>
To: David L Miller <>
Subject: =?iso-8859-1?Q?Test_MIME_message_with_RFC-1522_headers_=28=E1?=    =?iso-8859-1?Q?=E2=E3=29?=
Message-Id: <>
Mime-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-1737669234-826673975=:21583"
Content-Id: <>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to for more info.

Content-ID: <>

The text of the message would go here. It is readable if
one doesn't mind wading around a little bit of the MIME
formatting. After this is a binary file in base 64

|\ |  |\/|  David L. Miller  (206) 685-6240
|/ |_ |  |  Software Engineer, Pine Development Team   (206) 685-4045 (FAX)
University of Washington, Networks & Distributed Computing, JE-20
4545 15th Ave NE, Seattle WA 98105, USA

Content-Transfer-Encoding: BASE64
Content-ID: <>
Content-Description: Test Attachment


For details about Pine's implementation of MIME, see the two MIME sections "MIME: Reading a Message" and "MIME: Sending a Message" later in this document.

Folder Collections

Folder Collections are Pine's way of dealing with more than a single group of folders. With advent of PC-Pine and the development of tools within IMAP to better manage remote folders, the time was ripe to provide a mechanism for defining a group of remote folders. PC-Pine forced the issue in that many potential PC-Pine users would be migrating from UNIX Pine in a time-sharing environment and, thus, would have some investment in their archived messages on that host.

For a more complete description of Folder Collections, see the section on "Syntax for Collections."

The Pine distribution is designed to require as little configuration and effort at compile time as possible. Still, there are some Pine behaviors which are set at the time you compile Pine. For each of these, there is a reasonable (our opinion) default built into the code, so most systems administrators will have no need for these steps.