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:

olive.cac.washington.edu
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.

Alpine 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 Alpine configuration file, or rely on the file /etc/hosts which usually sets the name of the local host. While Alpine 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. For example,

128.95.112.99 olive.cac.washington.edu olive
is preferred over
128.95.112.99 olive olive.cac.washington.edu

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 Alpine configuration file (PINERC).

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

RFC 2822 Compliance

Alpine tries to adhere to RFC 2822 fairly strictly.

As far as outgoing email is concerned, Alpine 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. Alpine 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 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 2822 appear in the full name, quotes are required around the address. Alpine will insert the quotes automatically if needed. The common cases where this happens are with periods after initials and parentheses.

Alpine 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 shown as question marks in the FOLDER INDEX screen.

SMTP and Sendmail

Alpine is a user agent not a message transfer agent (MTA). In plain English, that means Alpine does not know how to interact with other computers on the Internet to deliver or receive email. What Alpine 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 an SMTP server or to a mail transfer agent. A common mail transfer agent is sendmail. The usual method of delivery used by Alpine is to use either a local or a remote SMTP server.

The selection of which MTA to use depends on the settings of smtp-server, sendmail-path, and compile-time options. The first MTA specified in the following list is used:

  1. sendmail-path in /etc/pine.conf.fixed
  2. smtp-server in /etc/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 /etc/pine.conf
  8. smtp-server in /etc/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. This method is not recommended unless there are special reasons you want to do this.

If an smtp-server is specified, Alpine operates 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, Alpine 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 Alpine 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 alternate SMTP servers. PC-Alpine only runs as an SMTP client so the smtp-server option is mandatory.

For UNIX Alpine, if neither smtp-server or sendmail-path is set, the default sendmail program is invoked with the "-bs -odb -oem" flags, and the message is sent using the SMTP protocol.

Internet Message Access Protocol (IMAP)

IMAP is a remote access protocol for message stores. Alpine uses IMAP to get at messages and folders which reside on remote machines. With IMAP, messages are kept on the server. An IMAP client (such as Alpine) can request specific messages, headers, message structures, message parts, 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."

IMAP Features:

IMAP4rev1 is described in RFC 3501. Further information about IMAP may be obtained from the University of Washington's IMAP Information Center.

Alpine 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 Alpine 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.

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.

An actual MIME message looks something like this: 

Date: Tue, 12 Mar 1996 15:39:35 -0800 (PST)
From: David L Miller <dlm@cac.washington.edu>
To: David L Miller <dlm@cac.washington.edu>
Subject: =?iso-8859-1?Q?Test_MIME_message_with_RFC-1522_headers_=28=E1?=    =?iso-8859-1?Q?=E2=E3=29?=
Message-Id: <Pine.ULT.3.92.960312150851.21583I-101000@shiva2.cac.washington.edu>
Mime-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-1737669234-826673975=:21583"
Content-Id: <Pine.ULT.3.92.960312153928.21583O@shiva2.cac.washington.edu>

  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 mime@docserver.cac.washington.edu for more info.

--0-1737669234-826673975=:21583
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.ULT.3.92.960312153104.21583L@shiva2.cac.washington.edu>

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
encoding.

|\ |  |\/|  David L. Miller    dlm@cac.washington.edu  (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

--0-1737669234-826673975=:21583
Content-Type: APPLICATION/ZIP; NAME="test.zip"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.ULT.3.92.960312153638.21583N@shiva2.cac.washington.edu>
Content-Description: Test Attachment

UEsDBBQAAAAIAGh8bCBbZKT4ygIAAHgFAAAEAAAAdGVzdIVUX2vbMBB/16c4
9rSBNyjsYX1UHSUROLInycv2qNhKI5ZYxlLa5dvvpDRLw6CFgJF09/t3Rxo3
WDBDD43rPJjJQpxMbw9m+h3AbyHuLLSDe7JTcPGUbtYm7NzwGP3wBYQnnT8c
7NQ5s4djsC8t4QbmYE6wsfjpLTy7uPPHCOPk/ATPk4vRDmS008GF4PzwPich
zY3m4LfxOQlPNy4GcEO3P/a2h2j/xGyp9ONpco+7CHf33+4/393ff4XNibzL
c1UVfXJXQIdIBRx877b4TYy9C3Fym2NEyzsX/pNDet8dD3aIJiagLbo2wwnG
4zT6cK66ZLK1NhH9J4tcZQEy7OxkNyd4nMwQbV9glP7JZb87E3O32fgnm7We
XQ8+us4SM47WTCkgMPt9enc2ZAW5c+Pj7o32l0IXXk/r8pSRE3A4jqOfIqqF
G+PFlSdRDOaQduXNESTwtDcYfJ8191gWXUjYmOJ43Oxdh11JTzRuSPcY37+B
vNqmf0O5RB1G27mt64rLCp4X8pW1L6BvxunCeYHNk3F7s9lb+GAwyvAhOyNE
Lxm0gv9gUnH9C+o5rKlacrHQtYAZV2VF+UoBrSp8kJIKzZkqgP1sJFMKagl8
1VSczQqy5noJki2onIGuQS+5AlXPNfaxArgoq3aGwJDq6lZDxVdcU82RKMG/
4JArTVKzYrJc4pE+8CoJpGIGc65FIp8jO4WGSs3LtqISmlY2tUKyVMUFETWw
H0xoUMvE8KbXB4aC6EPFzrDiF6iGlZxWBeFixiUrdXJb1kKx7y2C4hPM6Iou
WI4hdVyO6yXVqkZqiXmottLJ9lzWK1LVKttqk8oZ1TS1NrJGS5jqeslQI0aK
ieCvzNlgNZJqiccCc5WafLxmKdii4gsmSvYpISkteamzkRwXJiG5SoUpcERK
8xIE8QQ7o+eh5WAUy1qYRP8rioip/maI+OfyF1BLAQIUAxQAAAAIAGh8bCBb
ZKT4ygIAAHgFAAAEAAAAAAAAAAEAAACkgQAAAAB0ZXN0UEsFBgAAAAABAAEA
MgAAAOwCAAAAAA==
--0-1737669234-826673975=:21583--
For details about Alpine'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 Alpine's way of dealing with more than a single group of folders.

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

The Alpine distribution is designed to require as little configuration and effort at compile time as possible. Still, there are some Alpine behaviors which are set at the time you compile Alpine. 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.