debug ANSI_X3.4-1968
debug ANSI_X3.4-1968
                    Notes on Configuration and Preferences

Pine in Function Key Mode

   The  standard Pine uses alphabetic keys for most commands, and control
   keys  in  the  composer.  Despite  possible  appearances,  the current
   bindings  are  the  result  of  much  discussion  and thought. All the
   commands  in  the  composer  are single control characters. This keeps
   things  very  neat and simple for users. Two character commands in the
   composer  are a possibility, but we're trying to avoid them because of
   the added complexity for the user.

   Pine  can  also  operate  in a function-key mode. To go into this mode
   invoke  pine -k or (on some UNIX systems) pinef. On a UNIX system, you
   can  link  or  copy  the  Pine  executable  to pinef to install pinef.
   Alternatively,   users   and   systems   administrators  can  set  the
   use-function-keys   feature   in  the  personal  or  system-wide  Pine
   configuration file. The command menus at the bottom of the screen will
   show  F1-F12 instead of the alphabetic commands. In addition, the help
   screens  will  be written in terms of function keys and not alphabetic
   keys.

   One  of  the  results of using Pine in function-key mode is that users
   can   only   choose  from  twelve  commands  at  any  given  time.  In
   alphabetic-key  mode,  a user can press a key for a command (say, q to
   quit)  and  that  command  can be fulfilled. In function-key mode, the
   command  must  be  visible on the bottom key-menu in order to be used.
   There are some screens where four screens of commands are operational;
   function-key users can get to all of them, just not all at once.
     _________________________________________________________________

Domain Settings

   Pine  uses  the default domain for a few different tasks. First, it is
   tacked  onto the user-id for outgoing email. Second, it is tacked onto
   all  "local"  (unqualified)  addresses in the "To:" or "Cc:" fields of
   messages  being composed (unless they are found in the address book or
   on  an  LDAP  server).  The  domain  name  is  also  used  to generate
   message-id  lines for each outgoing message and to allow Pine to check
   if an address is that of the current Pine user.

   Pine  determines  the  domain  name according to whichever of these it
   finds. The list here is in decreasing order of precedence.
    1. Value   of   the   variable   user-domain   in  the  system  fixed
       configuration file
    2. Value  of  the  variable user-domain in the personal configuration
       file
    3. Value of the variable user-domain in the system-wide configuration
       file
    4. Value from an external database (DNS, /etc/hosts, NIS) as modified
       by  a  system fixed configuration file if use-only-domain-name set
       to yes
    5. Value from an external database (DNS, /etc/hosts, NIS) as modified
       by  a  personal  configuration file if use-only-domain-name set to
       yes
    6. Value from an external database (DNS, /etc/hosts, NIS) as modified
       by a system configuration file if use-only-domain-name set to yes
    7. Unmodified value (host name) from an external database

   The  easiest way for this system to work is for PC-Pine users and UNIX
   Pine  system  administrators  to  set  the  user-domain  variable. The
   variable    use-only-domain-name    is    helpful    if    your   site
   supports/requires  hostless  addressing, but for some reason you don't
   want to use the user-domain variable.
     _________________________________________________________________

Syntax for Collections

   In  many  environments,  it  is  quite  common  to have collections of
   archived  mail  on  various hosts around the network. Using the folder
   collections  facility  in  Pine,  access  to these archives is just as
   simple as access to folders on Pine's local disk.

   "Collection"  is the word we use in Pine to describe a set of folders.
   A  collection  corresponds  loosely  to  a "directory" containing mail
   folders.  Folders  within  a  defined  collection  can  be manipulated
   (opened,  saved-to,  etc)  using just their simple name. Any number of
   folder  collections can be defined, and Pine will adjust its menus and
   prompts to help navigate them.

   The way collections are defined in Pine is with the folder-collections
   variable  in  the  Pine configuration file. Folder-collections takes a
   list  of  one  or  more  collections,  each (optionally) preceded by a
   user-defined  logical name (label). Once collections are defined, Pine
   adjusts its menus and behavior to allow choosing files by their simple
   name within the collection.

   Consider the following:
   folder-collections=  Local-Mail      C:\MAIL\[],
                        Remote-Mail     {imap.u.example.edu}mail/[]

   The  example  shows  two  collections defined (a comma separated list;
   newlines  in  the list are OK if there's one or more spaces before the
   next   entry),  one  local  and  one  remote.  Each  collection  is  a
   space-delimited  pair  of  elements-first an optional logical-name and
   second  the  collection specifier. The logical-name can have spaces if
   it  has  quotes  around  it  (but  keeping  the logical name short and
   descriptive  works best). Pine will use the logical-name (if provided)
   to  reference  all folders in the collection, so the user never has to
   see the ugliness of the collection specifier.

   The  collection specifier can be thought of as an extended IMAP format
   (see  the  Remote  Folders  section  for  a description of IMAP format
   names).  Basically,  a pair of square-brackets are placed in the fully
   qualified IMAP path where the simple folder name (the part without the
   host  name  and  path) would appear. Like IMAP, the path can be either
   fully  qualified  (i.e.,  with a leading '/') or relative to your home
   directory.

   An  advanced  feature  of  this  notation is that a pattern within the
   square  brackets allows the user to define a collection to be a subset
   of a directory. For example, a collection defined with the specifier:
        M-Mail          C:MAIL/[m*]

   will  provide  a  view in the folder lister of all folders in the PC's
   "C:MAIL"  directory  that  start with the letter 'm' (case insensitive
   under  DOS,  of  course).  Further,  the  wildcard matching will honor
   characters trailing the '*' in the pattern.

   From  within Pine, the "Folder List" display will be adjusted to allow
   browsing  of  the folders in any defined collection. Even more, you'll
   notice  in the Goto and Save commands a pair of sub-commands to rotate
   through  the  list  of logical collection names, so only a simple name
   need be input in order to operate on a folder in any collection.

   The  first  collection specified in the folder-collections has special
   significance.  That  folder  is the "default collection for saves". By
   default,  in  cases  where  the user does not specify which collection
   should  be  used  to  Save a message, the default collection for saves
   will  be  used. Also, if the default-fcc is a relative file name, then
   it  is  relative  to  the  default  collection  for  saves.  (See also
   saved-msg-name-rule.

   The  notion  of  collections  encompasses  both email folders and news
   reading.  The variable news-collections uses nearly the same format as
   folder-collections.  Newsgroups  can  be defined for convenient access
   via  either  IMAP  or  NNTP. There are advantages and disadvantages to
   both  access methods. In the IMAP case, your news environment state is
   maintained  on  the  server and, thus, will be seen by any client. The
   downside  is  that,  at  the  moment,  you must have an account on the
   server.  In  the  NNTP  case, server access is mostly anonymous and no
   state/accounting  need  be maintained on it. The downside is that each
   client, for now, must individually maintain news environment state.

   An example pinerc entry might be:
     news-collections=  Remote-State    {news.u.example.edu}#news.[],
                        Local-State     {news.u.example.edu/nntp}#news.[]

   Only  newsgroups  to  which  you  are  subscribed  are included in the
   collection.

   The  pattern  matching  facility can be applied so as to define a news
   collection  which  is a subset of all the newsgroups you subscribe to.
   For example, this could be a valid collection:
                        Newsfeed-News   {news.u.example.edu/nntp}#news.[clari.*
]

   Collection  handling is a tough problem to solve in a general way, and
   the explanation of the syntax is a bit ugly. The upside is, hopefully,
   that  for  a  little complexity in the Pine configuration file you get
   simple management of multiple folders in diverse locations.

   As    of   Pine   4.00,   collection   setup   is   handled   by   the
   Setup/collectionList  screen  instead of requiring hand editing of the
   configuration file.
     _________________________________________________________________

Syntax for Remote Folders

   Remote  folders are distinguished from local folders by a leading host
   name  bracketed  by  '{' and '}'. The path and folder name immediately
   following  the closing bracket, '}', is interpreted by the IMAP server
   and  is  in  a form compatible with that server (i.e., path delimiters
   and naming syntax relative to that server).

   Typically, a folder name without any path description is understood to
   reside  in  the  user's "home directory" (i.e., in some way the user's
   personal,  writable  file  area), as are incomplete path designations.
   However,  the  IMAP  specification  does  not require that unqualified
   folder  names  live  in one's home directory, so some IMAP servers may
   require   fully  qualified  names.  An  example  of  a  remote  folder
   specification would be,
        {host.dept.washington.edu}mail/saved-messages

   This example simply specifies a folder named ``saved-messages'' on the
   imap server ``host.dept.washington.edu'', in the ``mail'' subdirectory
   of the user's home directory. Easy isn't it?

   To  confuse things a bit, qualifiers are permitted within the brackets
   following  the  host  name.  These qualifiers consist of a slash ('/')
   character  followed  by  a  keyword or keyword and value, and have the
   effect  of modifying how the connection is made to the host specified.
   An example of such a specification might be,
        {news.u.washington.edu/nntp}#news.comp.mail.mime

   This  specifies  an altogether different access method: access via the
   Network News Transport Protocol (NNTP).

   Some other possible qualifiers are /user=username, which says to login
   as  user  username;  /secure,  which  says  to  use  the  most  secure
   authentication  method  supported  by  Pine and the server and fail to
   connect  if  that  authentication  fails;  /imap; /pop3; /debug; /ssl,
   which  says  to  use  a secure SSL connection; /novalidate-cert, which
   tells  Pine  to  not attempt to validate certificates from SSL server;
   and /anonymous.

   There  is also an optional :portnum following the hostname. This would
   specify a non-standard port number to connect to.
     _________________________________________________________________

Sorting a Folder

   The  mail  index  may be sorted by arrival, date, subject, from, size,
   score,  to,  or  cc order. Each sort order can also be reversed. The $
   command  will  prompt  the user for the sort order. The sort order can
   also  be  specified  on  the  command  line  with  the  -sort  flag or
   (equivalently)  with  the sort-key variable in the pinerc file. When a
   user changes folders, the sort order will go back to the original sort
   order.   The   command   line   (-sort)  or  configuration  file  sort
   specification (sort-key) changes the original sort order.

   When  a folder is sorted and new mail arrives in the folder it will be
   inserted  in  its properly sorted place. This can be a little odd when
   the  folder  is sorted by something like the subject. It can also be a
   little  slow if you are viewing a large, sorted INBOX, since the INBOX
   will have to be re-sorted whenever new mail arrives.

   The  sorts  are all independent of case and ignore leading or trailing
   white  space. There are actually two forms of subject sort. One called
   Subject  and  the  other called OrderedSubj. They both ignore "Re:" at
   the  beginning  and  "(fwd)" at the end of the subjects. Subject sorts
   all   the  subjects  alphabetically.  OrderedSubj  sorts  by  subjects
   alphabetically,    groups    messages    with    the    same   subject
   (pseudo-threads),  then  sorts  the  groups  by  the date of the first
   message  of  the  group. Sorting by Thread was added after OrderedSubj
   and is usually a better method. Thread sorting uses information in the
   message  headers  References,  Message-ID, and Subject. It is possible
   the  sort  will  be  slightly  slower  with a Thread sort than with an
   OrderedSubj sort. The sort by sender sorts by the user-id (part before
   the  "@"),  not  the full name. The arrival sort is no sort at all and
   the  date  sort  depends  on the format of the date. Some dates are in
   strange  formats  and are unparsable. The time zone is also taken into
   account.

   Sorting large mail folders can be very slow since it requires fetching
   all  the  headers of the mail messages. With UNIX Pine, only the first
   sort is slow since Pine keeps a copy of all the headers. One exception
   is  sorting  in reverse arrival order. This is fast because no headers
   have to be examined. Pine will show progress as it is sorting.
     _________________________________________________________________

Alternate Editor

   In the Pine composer you can use any text editor, such as vi or emacs,
   for  composing  the message text. The addresses and subject still must
   be edited using the standard Pine composer. If you include the feature
   enable-alternate-editor-cmd  in  your  pinerc you can type ^_ while in
   the  body  of  the  message  in  the  composer and be prompted for the
   editor.  If  you  also  set the editor variable in your pinerc then ^_
   will invoke the configured editor when you type it.

   Turning   on   the   feature  enable-alternate-editor-implicitly  will
   automatically  invoke  the  editor  you  have  defined with the editor
   variable  whenever  you enter the body of a message you are composing.
   For  example,  when  you move out of the last header line and into the
   body  of  the  message,  the  alternate  editor  will be automatically
   invoked.

   We  know  that  many  people would like to use the alternate editor to
   edit  the  mail header as well. We considered several designs for this
   and  didn't  come  up  with  one  that  we  liked and that was easy to
   implement.  One  of  the  main problems is that you lose access to the
   address book.
     _________________________________________________________________

Signatures and Signature Placement

   If  the  file  ~/.signature  (UNIX) or <PINERCdirectory>\PINE.SIG (PC)
   exists,  it  will be included in all outgoing messages. It is included
   before composition starts so that the user has a chance to edit it out
   if  he or she likes. The file name for the signature can be changed by
   setting  the  signature-file  variable  in  the pinerc. If the feature
   enable-sigdashes  is  turned  on then the line consisting of the three
   characters  "-- " is prepended to the signature file. When Replying or
   Forwarding a message different signatures my be automatically included
   by  configuring  them  in the Roles setup screen. It's easy to include
   different  signatures  by  hand,  by  having  multiple signature files
   (.sig1,  .sig2,  .sig3,  etc)  and  choosing  to  include  (^R  in the
   composer) the correct one for the message being sent.

   Pine's   default  behavior  encourages  a  user  to  put  his  or  her
   contribution  before the inclusion of the original text of the message
   being  forwarded  or replied to, This is contrary to some conventions,
   but  makes the conversation more readable when a long original message
   is  included in a reply for context. The reader doesn't have to scroll
   through  the original text that he or she has probably already seen to
   find the new text. If the reader wishes to see the old message(s), the
   reader  can  scroll  further into the message. Users who prefer to add
   their input at the end of a message should set the signature-at-bottom
   feature. The signature will then be appended to the end of the message
   after  any included text. This feature applies when Replying, not when
   Forwarding.
     _________________________________________________________________

Feature List Variable

   Pine  used  to have feature levels for users with different amounts of
   experience.  We  found  that  this was too restrictive. Pine now has a
   feature-list  instead.  Each  user  may pick and choose which features
   they  would  like  enabled  (simple to do in the Setup/Config screen).
   There  is a short description of each in Configuration Features. There
   is  also  a  short  on-line  help explaining the effect of each of the
   features in the Setup/Config screen. When the cursor is highlighting a
   feature,  the  ?  command  will  show  the help text for that feature.
   Features  don't  have values, they are just turned on or off. They are
   all off by default.

   The  feature-list  variable  is different from all other configuration
   variables  in  that  its  value  is additive. That is, the system-wide
   configuration  file  can  have some features turned on by default. The
   user  can  select  other features in their personal configuration file
   and  those  features will be added to the set of features turned on in
   the  system-wide  configuration  file.  (With  all other configuration
   variables,   the   user's  values  replace  the  system-wide  values.)
   Likewise,  additional features may be set on the command-line with the
   argument "-feature-list=". These will be added to the others.

   The  treatment  of feature-list in the system-wide fixed configuration
   file is also different from other variables. The system management can
   fix  the  value  of  individual  features by placing them in the fixed
   configuration  file.  Users  will not be able to alter those features,
   but  will  still  be able to set the other non-restricted features the
   way they like.

   Because  feature-list is additive, there is a way to turn features off
   as  well  as on. Prepending the prefix "no-" to any feature sets it to
   off.  This  is  useful  for over-riding the system-wide default in the
   personal configuration file or for over-riding the system-wide default
   or  the personal configuration value on the command line. For example,
   if  the system-wide default configuration has the quit-without-confirm
   feature  set,  the  user  can  over-ride  that  (and  turn  it off) by
   including  no-quit-without-confirm  in the personal configuration file
   or by giving the command line argument
   -feature-list=no-quit-without-confirm. More features (options) will no
   doubt continue to be added.
     _________________________________________________________________

Configuration Inheritance

   We  start  with  an explanation of how configuration works in hopes of
   making it easier to describe how inheritance works.

   Pine   uses   a  hierarchy  of  configuration  values  from  different
   locations.  There  are  five  ways  in which each configuration option
   (configuration variable) can be set. In increasing order of precedence
   they are:

    1. the system-wide configuration file.
    2. the personal configuration file
    3. the personal exceptions file
    4. a command line argument
    5. the system-wide fixed configuration file (Unix Pine only)

   The fixed configuration file is normally /etc/pine.conf.fixed.

   The system-wide configuration file is normally /etc/pine.conf for Unix
   Pine  and  is  normally  not  set  for  PC-Pine.  For  PC-Pine, if the
   environment   variable   $PINECONF  is  set,  that  is  used  for  the
   system-wide  configuration. This location can be set or changed on the
   command  line with the -P flag. The system-wide configuration file can
   be either a local file or a remote configuration folder.

   For  Unix  Pine,  the personal configuration file is normally the file
   .pinerc  in the user's home directory. This can be changed with the -p
   command  line flag. For PC-Pine, the personal configuration file is in
   $PINERC  or  <PineRC registry value> or $HOME\PINE\PINERC or <PINE.EXE
   dir>\PINERC.  This can be changed with the -p command line flag. If -p
   or $PINERC is used, the configuration data may be in a local file or a
   remote config folder.

   For Unix Pine, the personal exceptions configuration file is specified
   with    the    "-x    exceptions_config"    command   line   argument.
   "Exceptions_config"   may   be   either  a  local  file  or  a  remote
   configuration  folder.  If  there is no "-x" command line option, Pine
   will  look  for  the file ".pinercex" in the same local directory that
   the  regular  config file is located in. If the regular config file is
   remote then Unix Pine looks in the home directory for ".pinercex".

   For  PC-Pine,  the personal exceptions configuration file is specified
   with  the "-x exceptions_config" command line argument. If there is no
   "-x"  command  line argument the environment variable $PINERCEX may be
   set    to    the    name    of    the   "exceptions_config"   instead.
   "Exceptions_config"   may   be   either  a  local  file  or  a  remote
   configuration  folder.  If  there  is  no "-x" command line option and
   $PINERCEX is not set, PC-Pine will look for the file "PINERCEX" in the
   same  local  directory  that the regular config file is located in. If
   the  regular  config  file  is  remote then PC-Pine looks in the local
   directory   specified  by  the  "-aux  local_directory"  command  line
   argument,  or the directory $HOME\PINE, or in <PINE.EXE directory> for
   a file named "PINERCEX".

   To  reiterate,  the  value of a configuration option is taken from the
   last location in the list above in which it is set. Or, thinking about
   it  slightly differently, a default value for an option is established
   in  the system-wide configuration file (or in the source code if there
   is  no  value in the system-wide file). That default remains in effect
   until  and  unless  it  is overridden by a value in a location further
   down  the list, in which case a new "default" value is established. As
   we  continue  down the list of locations we either retain the value at
   each  step or establish a new value. The value that is still set after
   going  through  the  whole  list of configuration locations is the one
   that is used.

   So,  for example, if an option is set in the system-wide configuration
   file  and  in  the  personal configuration file, but is not set in the
   exceptions,  on the command line, or in the fixed file; then the value
   from  the  personal configuration file is the one that is used. Or, if
   it  is  set  in the system-wide config, in the personal config, not in
   the  exceptions, but is set on the command line; then the value on the
   command line is used.

   Finally  we  get  to  inheritance. For configuration options which are
   lists,  like  "smtp-server"  or  "incoming-folders",  the  inheritance
   mechanism  makes  it  possible  to  combine  the values from different
   locations  instead  of  replacing  the  value.  This  is  true  of all
   configuration  lists  other than the "feature-list", for which you may
   already  set whatever you want at any configuration location (by using
   the "no-" prefix if necessary).

   To  use inheritance, set the first item in a configuration list to the
   token  "INHERIT".  If  the  first  item  is "INHERIT", then instead of
   replacing  the  default value established so far, the rest of the list
   is  appended  to  the default value established so far and that is the
   new value.

   Here is an example which may make it clearer. Suppose we have:

 System-wide config :   smtp-server = smtp1.corp.com, smtp2.corp.com
 Personal config    :   smtp-server = INHERIT, mysmtp.home
 Exceptions config  :   smtp-server = <No Value Set>
 Command line       :   smtp-server = <No Value Set>
 Fixed config       :   smtp-server = <No Value Set>

   This would result in an effective smtp-server option of

 smtp-server = smtp1.corp.com, smtp2.corp.com, mysmtp.home

   The  "INHERIT" token can be used in any of the configuration files and
   the effect cascades. For example, if we change the above example to:

 System-wide config :   smtp-server = smtp1.corp.com, smtp2.corp.com
 Personal config    :   smtp-server = INHERIT, mysmtp.home
 Exceptions config  :   smtp-server = INHERIT, yoursmtp.org
 Command line       :   smtp-server = <No Value Set>
 Fixed config       :   smtp-server = <No Value Set>

   This would result in:

 smtp-server = smtp1.corp.com, smtp2.corp.com, mysmtp.home, yoursmtp.org

   Unset  variables  are  skipped  over  (the  default  value  is carried
   forward) so that, for example:

 System-wide config :   smtp-server = smtp1.corp.com, smtp2.corp.com
 Personal config    :   smtp-server = <No Value Set>
 Exceptions config  :   smtp-server = INHERIT, yoursmtp.org
 Command line       :   smtp-server = <No Value Set>
 Fixed config       :   smtp-server = <No Value Set>

   produces:

 smtp-server = smtp1.corp.com, smtp2.corp.com, yoursmtp.org

   If  any later configuration location has a value set (for a particular
   list  option)  which  does  not  begin with "INHERIT", then that value
   replaces  whatever  value  has been defined up to that point. In other
   words, that cancels out any previous inheritance.

 System-wide config :   smtp-server = smtp1.corp.com, smtp2.corp.com
 Personal config    :   smtp-server = INHERIT, mysmtp.org
 Exceptions config  :   smtp-server = yoursmtp.org
 Command line       :   smtp-server = <No Value Set>
 Fixed config       :   smtp-server = <No Value Set>

   results in:

 smtp-server = yoursmtp.org

   For   some   configuration   options,   like   "viewer-hdr-colors"  or
   "patterns-roles",  it  is difficult to insert the value "INHERIT" into
   the  list  of  values  for the option using the normal Setup tools. In
   other words, the color setting screen (for example) does not provide a
   way   to   input   the  text  "INHERIT"  as  the  first  item  in  the
   viewer-hdr-colors  option.  The  way  to do this is to either edit the
   pinerc   file  directly  and  manually  insert  it,  or  turn  on  the
   "expose-hidden-config"  feature  and  insert it using the Setup/Config
   screen.
     _________________________________________________________________

SMTP Servers

   It  is  sometimes  desirable  to  set smtp-server=localhost instead of
   setting  sendmail-path  to  overcome  the inability to negotiate ESMTP
   options when sendmail is invoked with the -t option. Sendmail can also
   be  subject  to  unacceptable delays due to slow DNS lookups and other
   problems.

   It is sometimes desireable to configure an SMTP server on a port other
   than  the  default  port  25. This may be used to provide an alternate
   service  that  is  optimized  for a particular environment or provides
   different  features  from  the  port  25 server. An example would be a
   program  that  negotiates ESMTP options and queues a message, but does
   not  attempt  to  deliver messages. This would avoid delays frequently
   encountered when invoking sendmail directly.

   A typical configuration would consist of
     * A program that implements the SMTP or ESMTP protocol via stdio.
     * An entry in /etc/services for the alternate service.
     * An entry in /etc/inetd.conf for the alternate service.
     * An entry in /etc/pine.conf, /etc/pine.conf.fixed or ~/.pinerc.
     _________________________________________________________________

MIME.Types file

   Pine's  MIME-TYPE support is based on code contributed by Hans Drexler
   &LT;drexler@mpi.nl&GT;.  Pine  assigns MIME Content-Types according to
   file    name    extensions    found    in    the   system-wide   files
   /usr/local/lib/mime.types  and  /etc/mime.types,  and  a user specific
   ~/.mime.types file.

   In  DOS  and OS/2, Pine looks in the same directory as the PINERC file
   and  the  same  dir as PINE.EXE. This is similar to the UNIX situation
   with  personal  config  info  coming  before potentially shared config
   data.  An  alternate  search  path  can  be  specified  by setting the
   mimetype-search-path variable in the user or system-wide configuration
   or by setting the MIMETYPES environment variable.

   These  files  specify file extensions that will be connected to a mime
   type. Lines beginning with a '#' character are treated as comments and
   ignored.  All  other  lines are treated as a mime type definition. The
   first  word  is  a type/subtype specification. All following words are
   file extensions belonging to that type/subtype. Words are separated by
   whitespace characters. If a file extension occurs more than once, then
   the  first  definition  determines the file type and subtype. A couple
   sample lines from a mime.types file follow:

image/gif         gif
text/html         html htm
video/mpeg        mpeg mpg mpe
     _________________________________________________________________

Color Details

   UNIX  Pine  may display color if the terminal or terminal emulator you
   are  using  is  capable of displaying colors. If the terminal supports
   ANSI  color  escape  sequences you will be able to turn color on using
   the  color-style  option and setting it to the value force-ansi-8color
   or  force-ansi-16color.  If  instead  you'd like Pine to automatically
   detect  whether or not you are on a color terminal, set color-style to
   use-termdef   and   configure  the  termcap  entry  to  describe  your
   terminal's color capabilities.

   If  the  color-style  option  is set to use-termdef, Pine looks in the
   terminal  capabilities database, TERMINFO or TERMCAP, depending on how
   Pine  was  compiled, to decide whether or not your terminal is capable
   of  color. For TERMINFO compiled Pines, the capabilities that are used
   for color are "colors", "setaf", "setab", "op", and "bce". If you have
   a  terminal with color capabilities described by the "scp" capability,
   Pine  does  not  support it. The capabilities "setf" and "setb" may be
   used  instead of "setaf" and "setab". The capability "bce" is optional
   and  is  used as an optimization, the other capabilities are required.
   For  TERMCAP  compiled Pines, the capabilities that are used for color
   are  "Co",  "AF", "AB", "op", and "ut". The capabilities "Sf" and "Sb"
   may  be  used  instead  of  "AF"  and "AB", though this isn't a useful
   feature.

   Here are some short descriptions of the capabilities listed above. The
   TERMINFO name is listed, followed by the TERMCAP name in parentheses.
   colors (Co)
          The number of different colors.
   setaf (AF)
          Set ANSI foreground color.
   setab (AB)
          Set ANSI background color.
   setf (Sf)
          Set foreground color. Alternate form of setaf.
   setb (Sb)
          Set background color. Alternate form of setab.
   op (op)
          Set default pair to its original value.
   bce (ut)
          Screen  is  erased  with  current  background  color instead of
          default background.

   A  standard  ANSI  terminal  which supports color will have a TERMINFO
   entry which contains:
  colors#8
  setaf=\E[3%p1%dm
  setab=\E[4%p1%dm
  op=\E[39;49m
  bce

   or the TERMCAP equivalent:
  Co#8
  AF=\E[3%dm
  AB=\E[4%dm
  op=\E[39;49m
  ut

   If  there  are eight colors, the program uses colors 0, 1, ..., 7. For
   an  ANSI  terminal,  the foreground color is set by sending the escape
   sequence  "Escape  LeftBracket  3 color_number m" to the terminal. The
   background  color is set by sending the sequence "Escape LeftBracket 4
   color_number  m".  ANSI  colors  zero  through seven are defined to be
   "black",  "red",  "green",  "yellow",  "blue",  "magenta", "cyan", and
   "white".  Some  terminal  emulators  will  swap  blue and red and swap
   yellow  and  cyan.  The  capabilities  "setf"  and  "setb" are usually
   designed  for those terminals so that they will flip the color numbers
   1  and 4 and the numbers 3 and 6 to compensate for this. Pine will use
   the  ANSI versions of the capabilities if they exist, and will use the
   non-ANSI  versions  (setf  and setb) if the ANSI versions don't exist.
   Here's  a  version which does the flipping. This can only be used with
   TERMINFO  Pines,  because of the arithmetic, which is not supported by
   TERMCAP.
  colors#8
  setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m
  setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m
  op=\E[39;49m
  bce

   Some  terminal  emulators  are capable of displaying eight more colors
   when  the  foreground  colors  30-37  are  replaced with 90-97 and the
   background  colors  40-47  are  replaced with 100-107. These terminals
   require  a  fancy termcap entry which can take foreground colors 0, 1,
   ...,  15  and  map  that  into  30,  31, ..., 37, 90, 91, ..., 97, and
   similarly  for  the  background colors. Here is a terminfo entry which
   will do just that:
  colors#16
  setaf=%p1%{8}%/%{6}%*%{3}%+\E[%d%p1%{8}%m%dm
  setab=%p1%{8}%/%{6}%*%{4}%+\E[%d%p1%{8}%m%dm
  op=\E[39;49m
  bce

   and here is the termcap equivalent:
  Co#16
  AF=\E[%i%i%>\001\034%>\045\064%dm
  AB=\E[%i%i%>\001\046%>\057\064%dm
  op=\E[39;49m
  ut

   This  is  a  terminfo  entry  for  16  colors that also does the color
   flipping:
  colors#16
  setf=%p1%{8}%/%{6}%*%{3}%+\E[%d%p1%{8}%m%Pa%?%ga%{1}%=%t4%e%ga%{3}%=%t6%e%ga%
{4}%=%t1%e%ga%{6}%=%t3%e%ga%d%;m
  setb=%p1%{8}%/%{6}%*%{4}%+\E[%d%p1%{8}%m%Pa%?%ga%{1}%=%t4%e%ga%{3}%=%t6%e%ga%
{4}%=%t1%e%ga%{6}%=%t3%e%ga%d%;m
  op=\E[39;49m
  bce

   If  you  are always using the same display it probably won't matter to
   you  if  the  color  pairs red/blue and cyan/yellow are flipped, since
   you'll  always be seeing them flipped. You will get different defaults
   than  on a display with them not flipped, but that's about all. If you
   are  trying  to  use the same pinerc file from displays with different
   color  characteristics,  or from Pine and PC-Pine, you will have to be
   more  careful.  The  colors  numbered 0 through 7 may be used portably
   between  different  systems if you are careful to make them correspond
   to  the ANSI order mentioned above. You can check this by looking at a
   color  configuration  screen  for  one  of the colors. The first eight
   colors  should  be  in  the order above. If they aren't, you could fix
   that  by  modifying your termcap entry on the UNIX system. This is not
   possible if your system uses TERMCAP instead of TERMINFO.
     _________________________________________________________________

Additional Notes on PC-Pine

   Below  are  a  few  odds and ends worth mentioning about PC-Pine. They
   have  to  do  with  DOS-specific  behavior that is either necessary or
   useful (and sometimes both!).

   As  PC-Pine  runs  in  an  environment  with  limited  access control,
   accounting  or  auditing, an additional line is automatically inserted
   into the header of mail messages generated by PC-Pine:
        X-Sender: <userid>@<imap.host>

   By  popular demand of system administrators, PC-Pine has been modified
   to  prevent  sending  messages  until the user has successfully logged
   into  a  remote  mail server. Even though PC-Pine cannot prevent users
   from  changing  the  apparent identity of the sender of a message, the
   IMAP  server  login  name  and host name included in the X-Sender line
   provide  some  level  of  traceability by the recipient. However, this
   should  not  be  considered  a  rigorous form of authentication. It is
   extremely   lightweight,   and   is   not   a   replacement  for  true
   authentication.

   Hand  in  hand with authentication and accounting is user information.
   Since   PC-Pine   has   no  user  database  to  consult  for  user-id,
   personal-name,  etc.,  necessary  information  must be provided by the
   user/installer  before  PC-Pine  can  properly  construct  the  "From"
   address  required  for  outbound  messages.  PC-Pine will, by default,
   prompt  for  the requisite pieces as they are needed. This information
   corresponds   to   the   PINERC   variables   user-id,  personal-name,
   user-domain, and smtp-server.

   The  user  is  then  asked  whether  or  not  this  information should
   automatically  be  saved  to  the  PINERC.  This is useful behavior in
   general,   but  can  lead  to  problems  in  a  lab  or  other  shared
   environment.   Hence,   these   prompts   and   automatic   saving  of
   configuration  can be turned off on an entry by entry basis by setting
   any of the above values in the PINERC to the null string (i.e., a pair
   of  double  quotes). This means that the user will be prompted for the
   information  once during each Pine session, and no opportunity to save
   them in the PINERC will be offered.

   Along  similar  lines,  a  feature  allowing  automatic  login  to the
   imap-server  containing the user's INBOX has also been requested. This
   feature  is  not enabled by default, but requires the existence of the
   file named PINE.PWD in the same directory as the PINERC. Even with the
   existence  of  this  file,  the  user  must still acknowledge a prompt
   before  the password is saved to the file. If PC-Pine is configured to
   access  several  different IMAP servers, each password entered will be
   kept  (associated  with  the corresponding host name) in memory during
   the  current  session, and optionally, in the PINE.PWD file for use in
   subsequent sessions.

   WARNING!  Use  this  feature  with  caution!  It effectively makes the
   user's  mail  no more secure than the physical security of the machine
   running  PC-Pine. What's more, while the password is cloaked by a mild
   (some  might say, feeble) encryption scheme, it is nonetheless sitting
   in  a  file  on  the  PC's disk and subject to cracking by anyone with
   access to it. BEWARE!

   Another  feature  of  DOS  is  the  lack  of standard scratch area for
   temporary  files.  During the course of a session, PC-Pine may require
   numerous  temporary files (large message texts, various caches, etc.).
   Where to create them can be a problem, particularly when running under
   certain  network  operating systems. PC-Pine observes the TMPDIR, TMP,
   and  TEMP  environment  variables,  and creates temporary files in the
   directory specified by either. In their absence, PC-Pine creates these
   files  in  the root of the current working drive. Some temporary files
   have  to  be  created  in  the  same  directory as the file they are a
   temporary copy of. For example, a pinerc file or a address book file.
