1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
|
<HTML><HEAD><TITLE>Alpine Technical Notes: Background Details</TITLE></HEAD><BODY>
<H1>Background Details</H1>
<H2><A NAME="DNS">Domain Names</A></H2>
<BR><P>
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:
<BLOCKQUOTE><CODE>
olive.cac.washington.edu
</CODE></BLOCKQUOTE>
In this domain name the top-level label is <EM>edu</EM>, indicating it is
at an educational institution, the second-level label is
<EM>washington</EM>, indicating the University of Washington.
<EM>cac</EM> is a specific department within the University of Washington,
and <EM>olive</EM> 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. <P>
<EM>Alpine</EM> 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. <P>
On UNIX systems, you can set the domain via the <A
HREF="config.html#user-domain"><EM>user-domain</EM></A>
variable in the <EM>Alpine</EM> configuration file, or rely on the file
<CODE>/etc/hosts</CODE> which usually sets the name of the local host.
While <EM>Alpine</EM> 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 <CODE>/etc/hosts</CODE>
file. The fully-qualified name should be listed before any abbreviations.
For example,
<BLOCKQUOTE><CODE>
128.95.112.99 olive.cac.washington.edu olive
</CODE></BLOCKQUOTE>
is preferred over
<BLOCKQUOTE><CODE>
128.95.112.99 olive olive.cac.washington.edu
</CODE></BLOCKQUOTE>
<P>
On PCs, the task of configuring the domain name is a bit different. Often
times PCs do not have domain names-they have <EM>IP addresses</EM>. 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 <A
HREF="installation.html#install-pc">PC specific installation notes</A> for
help configuring the IP address with your network software. <P>
With PCs, it is vital that users set the variable <A
HREF="config.html#user-domain"><EM>user-domain</EM></A> in the <EM>Alpine</EM>
configuration file (<CODE>PINERC</CODE>). <P>
Details on configuring <EM>Alpine</EM> with correct domain names can be
found in the <A HREF="config-notes.html#domain">Domain Settings</A>
section of this document. <P>
<HR>
<H2><A NAME="rfc2822">RFC 2822 Compliance</A></H2>
<EM>Alpine</EM> tries to adhere
to <A HREF="ftp://ftp.isi.edu/in-notes/rfc2822.txt">RFC 2822</A>
fairly strictly. <P>
As far as outgoing email is concerned, <EM>Alpine</EM> 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.
<EM>Alpine</EM> 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. <P>
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. <EM>Alpine</EM>
will insert the quotes automatically if needed. The common cases where this happens
are with periods after initials and parentheses. <P>
<EM>Alpine</EM> expects dates to be in the standard RFC 822 format
which is something like:
<PRE>
[www, ] dd mmm yy hh:mm[:ss] [timezone]
</PRE>
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. <P>
<HR>
<H2><A NAME="SMTP">SMTP and Sendmail</A></H2>
<EM>Alpine</EM> is a <EM>user agent</EM> not a <EM>message transfer agent</EM> (MTA). In
plain English, that means <EM>Alpine</EM> does not know how to interact with other
computers on the Internet to deliver or receive email. What <EM>Alpine</EM> 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. <P>
All outgoing email is delivered to an SMTP server
or to a mail transfer agent.
A common mail transfer agent is <CODE>sendmail</CODE>.
The usual method of delivery used by <EM>Alpine</EM> is to use either a
local or a remote SMTP server.
<P> The selection of which MTA to use depends on the settings of
<A HREF="config.html#smtp-server"><EM>smtp-server</EM></A>,
<A HREF="config.html#sendmail-path"><EM>sendmail-path</EM></A>,
and compile-time options.
The first MTA specified in the following list is used:
<OL>
<LI><EM>sendmail-path</EM> in
<CODE>/usr/local/lib/pine.conf.fixed</CODE>
<LI><EM>smtp-server</EM> in <CODE>/usr/local/pine.conf.fixed</CODE>
<LI><EM>sendmail-path</EM> specified on the command line.
<LI><EM>smtp-server</EM> specified on the command line.
<LI><EM>sendmail-path</EM> in the user's <CODE>.pinerc</CODE> file.
<LI><EM>smtp-server</EM> in the user's <CODE>.pinerc</CODE> file.
<LI><EM>sendmail-path</EM> in <CODE>/usr/local/lib/pine.conf</CODE>
<LI><EM>smtp-server</EM> in <CODE>/usr/local/pine.conf</CODE>
<LI><CODE>DF_SENDMAIL_PATH</CODE> defined at compile time.
<LI><CODE>SENDMAIL</CODE> and <CODE>SENDMAILFLAGS</CODE> defined at
compile time.
</OL><P>
If the <EM>sendmail-path</EM> 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.
<EM>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. </EM><P>
If an <EM>smtp-server</EM> is specified,
<EM>Alpine</EM> operates as an SMTP client. SMTP stands for <EM>Simple Mail
Transfer Protocol</EM>; it specifies the rules by which computers on the
Internet pass email to one another. In this case, <EM>Alpine</EM> 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 <EM>Alpine</EM> operate as an SMTP client, the
<A HREF="config.html#smtp-server"><EM>smtp-server</EM></A> 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.
<EM>PC-Alpine</EM> only runs as an SMTP client so the <EM>smtp-server</EM>
option is mandatory. <P>
For UNIX <EM>Alpine</EM>,
if neither <EM>smtp-server</EM> or <EM>sendmail-path</EM> is set,
the default <CODE>sendmail</CODE> program is
invoked with the "<CODE>-bs -odb -oem</CODE>" flags, and the message
is sent using the SMTP protocol.
<P>
<HR>
<H2><A NAME="IMAP">Internet Message Access Protocol (IMAP)</A></H2>
IMAP is a remote access protocol for message stores. <EM>Alpine</EM> 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 <EM>Alpine</EM>) 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 "<A
HREF="http://www.imap.org/imap.vs.pop.brief.html">Comparing Two Approaches
to Remote Mailbox Access: IMAP vs. POP</A>" by Terry Gray. A more
detailed exploration of message access may be found in the paper "<A
HREF="http://www.imap.org/imap.vs.pop.html"> Message Access Paradigms and
Protocols</A>."
<P>
IMAP Features:
<UL>
<LI> Allows access to mail folders from more than one client computer.
<LI> Works well over low-bandwidth lines because information is sent in
small pieces as needed by the user. For example, only header information
is sent to build index lists, and if someone sends a large audio file via
MIME, you can choose when (or if) you want to get that part of the
message.
<LI> Email can be delivered and stored on a well-maintained and reliable
server which is "always-up".
<LI> Folders can be accessed and manipulated from anywhere on the
Internet.
<LI> Users can get to messages stored in different folders within the same
<EM>Alpine</EM> session.
<LI> Allows use of IMAP server for searching and parsing.
<LI> The latest revision of IMAP (IMAP4) also provides for disconnected
operation, including resynchronization of message state between mail
servers and message caches on clients. <EM>Alpine</EM> does not support this
capability, however.
</UL>
IMAP4rev1 is described in <A
HREF="ftp://ftp.isi.edu/in-notes/rfc3501.txt">RFC 3501</A>. Further
information about IMAP may be obtained from the University of Washington's
<A HREF="http://www.washington.edu/imap/">IMAP Information Center</A>.<P>
<EM>Alpine</EM> is an IMAP4rev1 client.
<P>
<HR>
<H2><A NAME="MIME">Multipurpose Internet Mail Extensions (MIME)</A></H2>
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
<EM>Alpine</EM> 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. <P>
The MIME standard was officially published in June of 1992 as <A
HREF="ftp://ftp.isi.edu/in-notes/rfc1341.txt">RFC 1341</A> and subsequently
revised in <A HREF="ftp://ftp.isi.edu/in-notes/rfc2045.txt">RFC 2045</A>
when it became a full Internet Standard. <EM>Pine</EM> 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. <P>
The MIME standard also includes support for non-ASCII text in message
headers through the extensions described in <A
HREF="ftp://ftp.isi.edu/in-notes/rfc1342.txt">RFC 1342</A> and subsequently
revised in <A HREF="ftp://ftp.isi.edu/in-notes/rfc2047.txt">RFC 2047</A>. <P>
An actual MIME message looks something like this:
<PRE>
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--
</PRE>
For details about <EM>Alpine</EM>'s implementation of MIME, see the two MIME sections
"<A HREF="low-level.html#MIME-read">MIME: Reading a Message</A>" and
"<A HREF="low-level.html#MIME-send">MIME: Sending a Message</A>" later
in this document. <P>
<HR>
<H2><A NAME="collections">Folder Collections</A></H2>
Folder Collections are <EM>Alpine</EM>'s way of dealing with more than a single group
of folders. <P>
For a more complete description of Folder Collections, see the section on
"<A HREF="config-notes.html#collections">Syntax for Collections</A>." <P>
The <EM>Alpine</EM> distribution is designed to require as little configuration and
effort at compile time as possible. Still, there are some <EM>Alpine</EM> behaviors
which are set at the time you compile <EM>Alpine</EM>. 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. <P>
<!-- pnuts -->
</BODY>
</HTML>
|
