From: toney@milton.u.washington.edu (I met Elvis + lived...)
Newsgroups: comp.sys.att
Subject: pine
Date: 29 Sep 92 21:25:27 GMT
Article-I.D.: u.1992Sep29.212527.2055
Organization: University of Washington, Seattle

                            - Pine Technical Notes -


                              Pine Technical Notes
                             Version 3.0, July 1992




                Section I -- Installation, Design and Internals


          Building and Installation

               Hopefully, by this time you've already built  Pine  and
          tried  it  out.  If not, you should be able to do it without
          too much trouble by picking the platform you want  to  build
          it  for  and giving the command "./build xxx" where "xxx" is
          the three letter abbreviation for the  platform  name.   The
          list of these abbreviations is in the file "doc/pine-ports".
          You must be in the root of the source tree when you give the
          build command. If there's nothing in pine-ports for the sys-
          tem you have, building Pine and Pico will be a little  or  a
          lot more involved. The first thing to try is to pick a plat-
          form you think is close and try it, for example a  different
          version of the same operating system. If it doesn't work you
          can try another.  Giving the command "./build clean" between
          attempts  is a good idea. It makes sure you start the compi-
          lation from scratch each time. If nothing  works  then  some
          real  porting  will  have  to  be done.  See the sections on
          bugs, porting and source code below.   The  source  code  is
          about 4Mb and fully compiled it takes up 7-10Mb depending on
          the platform. You can do it in less space if you build  Pine
          and  Pico  by  hand  and delete .o files as you compile each
          library.


               When you're done building Pine  you  should  have  four
          binaries  in  the  bin directory. If they didn't all compile
          you may still be OK. The binary, imapd, is  only  needed  if
          you  want to operate pine in client-server mode and mtest is
          used mostly for testing imapd. The Pine binary is the mailer
          and  the  Pico  binary  is  a stand alone text editor that's
          similar to the message composer. Pico is not needed  to  run
          Pine or vice versa.


               Usually, all you need to do to install Pine and Pico is
          to copy the pine and pico binaries from the bin directory to
          the local system bin directory so they can be execute by all
          users.  /usr/local/bin is most frequently used.  /usr/bin is
          also a possible place but they will get mixed in  with  your
          standard system programs if you put them there. All the help
          text is compiled into Pine so there are no required  auxili-
          ary files.



                                     - 1 -

                            - Pine Technical Notes -


               There  are  however,  two  optional  auxiliary   files:
          /usr/local/lib/pine.info  and  /usr/local/lib/pine.conf. The
          first one is can contain text on how to get further help  on
          the  local system.  It is presented as the first page of the
          help text for the main menu and should probably refer to the
          local  help  desk  or the system administrator. If this file
          doesn't exist a suitably generic text is  shown  (that  sug-
          gests  sending  mail  to  root  as one way to get help). The
          other file is used to configure the 2 0 or so  options  that
          Pine  has.   See  the section on configuration in this docu-
          ment.

          Here's a step by step recipe:


          1.   Figure out what platform you're building Pine for.  You
               can give the command "./build help" to get a short list
               of platforms. If it's not in that list you can look  in
               the   file   doc/pine-ports  (give  the  command  "more
               doc/pine-ports" to view it). What you need is the three
               letter  code  for the platform. Some examples are "nxt"
               for a NeXT cubes and slabs and "ult" for Ultrix.


          2.   Make sure your in the root of the pine source. When you
               type "ls" you should see the following files and direc-
               tories:

                   README    build     contrib   imapd     pico
                   bin       c-client  doc       makefile  pine




          3.   You can make sure you're getting a clean start by  giv-
               ing the command "./build clean". This should take a few
               seconds to run.


          4.   Give the command "./build xxx" where "xxx" is the three
               letter  code  you picked in step 1. The compiler should
               grind away for 10 minutes or so. You shouldn't see  any
               compiler warnings or errors, though there might be some
               if your system doesn't match the system  you've  speci-
               fied to build.


          5.   When the compilation is complete the sizes of the  four
               binaries  built  will be displayed. The binaries are in
               the source directories with links to the  binaries  are
               in  the "bin" directories. You can just get them out of
               "bin".



                                     - 2 -

                            - Pine Technical Notes -


          Design goals


                Pine  was  designed  for  novice  computer  users.  To
          achieve  this,  features included were limited and carefully
          selected.  This may have made Pine less attractive for power
          users,  but  the  assumption  was that there were many power
          user e-mail tools available for UNIX systems. It seemed very
          important  to carefully consider questions that users asked.
          Advanced users are articulate about the changes  they  would
          like.   Beginning users are not articulate and may walk away
          confused, not commenting if a program doesn't work  out  for
          them.  Thus, if one continues development of a program based
          on users comments one may wind up  with  something  suitable
          for  advanced  users, but lose the beginning users.  To keep
          to the design goals, the questions users  asked  about  Pine
          were  examined  to  determine  the areas that weren't clear.
          That is, when a user asked a question it  was  assumed  that
          Pine  could  be  clearer about the way it worked rather than
          assuming the user didn't understand.


               Some other principles are:

           - The underlying model presented to the user has to be sim-
          ple  and  clear.  To  this  end a lot of UNIX is hidden. For
          example, there is a simple list of folders without hierarchy
          and pathnames.

           - It's better to have a  few  general,  easily  understood,
          commands that can be repeated than to have some more sophis-
          ticated command that will do the job all at  once.  This  is
          one reason Pine has no aggregate operations.

           - When ever the user has to select a  command,  file  name,
          address  etc,  the user is given a menu or can get a menu to
          make the selection from.  If possible the menu  is  as  com-
          plete  as  possible  (no  hidden  commands),  small and well
          thought out. This isn't entirely possible with  things  like
          addresses, but the address book helps.

           - Pine provides immediate feed back for the user with  each
          operation.

           - The system should be very tolerant  of  user  errors.  It
          should  warn  him if he's about do to something irreversible
          or provide a way to undo something. This way  the  user  can
          learn  by exploration with out fear of doing anything wrong.
          This is an important feature so the  user  can  get  started
          quickly without reading any manuals and so fewer manuals are
          required. (At the moment there isn't any manual anyway).

           - The size of the system should be kept small so  the  user


                                     - 3 -

                            - Pine Technical Notes -


          doesn't  feel like there are all these commands and concepts
          that he should know while using the system.


          IMAP (The Interactive Mail Access Protocol)


               Pine is capable of operating as  an  IMAP  client.  The
          syntax  for  naming  an  IMAP  mailbox is {hostname}mailbox.
          Hostname is a standard DNS hostname and mailbox is the  path
          of  the mail file to be opened. It may be "inbox" to specify
          the systems idea of the inbox, or it may be a file path name
          relative   to   the   users   home  directory.  For  example
          "mail/sent-mail". The remote host must be running  an  imapd
          and the user will be required to authenticate himself with a
          user name and password.


               If "rimap" authentication is enabled on the remote host
          an  .rhosts file on the server will allow the user to bypass
          typing the password.  This works by having  the  client  use
          the  standard  rsh  mechanism to connect to the server which
          results in two extra rsh processes on the client.  Basically
          what  is  happening here is that Pine is taking advantage of
          the ability that rsh has to use privileged TCP ports  so  it
          doesn't  have  to  run  in  privileged  mode. If the "rimap"
          authentication fails it will drop  back  to  plain  password
          authentication.  Enabling  "rimap" authentication is done by
          creating a link called rimapd to imapd.


               Installing imapd requires placing  the  binary  in  the
          appropriate  directory,  usually /usr/etc and adding entries
          to /etc/services and /etc/inetd.conf. The following line  is
          appropriate for /etc/services:

            imap         143/tcp         # Mail transfer

          and this next line is appropriate for /etc/inetd.conf:

            imap  stream  tcp     nowait  root    /usr/etc/imapd imapd

          The /etc/inetd.conf file entry may vary  on  different  ver-
          sions  of  UNIX.   Some  have  a  slightly  different set of
          fields. Also the path name in /etc/inetd.conf must match the
          path where imapd is installed.


               At this point one may ask, what is IMAP and why  is  it
          useful?  A  complete  answer would be fairly long. Basically
          IMAP is a mail access protocol as distinguished from a  mail
          transfer  protocol.   It's  intended  for  interactive  mail
          access. It's closest kin is POP, the Post  Office  Protocol,


                                     - 4 -

                            - Pine Technical Notes -


          but  it  exceeds POP in many ways. POP works by transferring
          an entire mailbox to the client where all the mail is  kept.
          IMAP retains all mail on the server and allows the client to
          retrieve mail as it's read and then send  commands  back  to
          the  server to specify what is to be done with the mail. The
          advantages of this is that it works well over low  bandwidth
          lines  because  only what's needed is transferred, then mail
          is cached on the client. However, POP is  appropriate  where
          connect  time charges are high. Other advantages of IMAP are
          that the mail is stored on a reliable,  always  up,  server;
          that the mail can be accessed from many different clients in
          different places and is not stuck on a PC (probably with  no
          backups);  and  that  it  allows  one  to  take advantage of
          cheaper CPU cycles on the desk top to drive the user  inter-
          face  rather than expensive cycles on time sharing machines.
          One imap client can also be  used  to  access  several  mail
          servers at once. The general idea is to run a mail client on
          the machine where a user has his home directory, to  facili-
          tate  moving  information between the mail system and user's
          file system, but to deliver mail to and maintain one's inbox
          on a high availability server.


               Currently, Pine supports having one's inbox remote  via
          IMAP.  This  feature  is  invoked  by entering a {host}inbox
          value for the inbox-path option either the global pine  con-
          figuration  file or in a users .pinerc file. Access to other
          remote folders require the users to type the full IMAP  mail
          box  specification.   Future plans include simpler access to
          remote folders other than inbox.


               Some other sources  of  information  are  RFC-1176  and
          imap-viewgraphs.ps  included  here.  You  can also fetch the
          whole   imap   source   tree   and   developers   kit   from
          ftp.cac.washington.edu.  The  IMAP protocol and the c-client
          library that implements it are authored by Mark Crispin.


          Address Formats (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 "address  (full  name)"  format.  The
          intent  of  the standard is that items in parenthesis should
          only be for comments.  Pine displays and generates the newer
          format,  but  will parse the old format and turn it into the
          new one.


               Pine also fully qualifies  all  addresses  on  outgoing
          mail  with  the  host  or  domain  name  as described in the


                                     - 5 -

                            - Pine Technical Notes -


          section on domain names. This makes addresses more clear and
          unambiguous  as  networks  get  larger and span greater dis-
          tances and gives a hint to the user that the network extends
          beyond  the  local organization.  Typing the fully qualified
          address is not required, just the user name  is  sufficient.
          When  the  user moves the cursor out of the header field the
          address will be expanded and  fully  qualified.   Note  that
          because  the  newer  format  is used, commas are required to
          separate addresses since the full name part may have  spaces
          in  it.   If  any  special  characters as defined in RFC-822
          appear in the full name,  quotes  are  required  around  the
          address.  Pine  will  insert  them automatically. The common
          cases where this happens are with periods after initials and
          parentheses.  A  good  substitute  for parentheses are curly
          braces. They are not considered special.


               On some UUCP connected machines and for UUCP addresses,
          fully  qualified  addresses  may  seem  to  confuse or break
          things. This is probably not the case  though,  because  the
          local  hostname  is what is added. The mailer will recognize
          it as the local hostname and drop  that  part  first  before
          going on to process the rest of the address.


               Pine also 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 index.


          Known Bugs and Problems


                In general, see the to-do-xxxx file included with this
          documentation.   At  the  U.W.  Pine  is used by 3,000 users
          every week, most of the bugs have been  shaken  out  of  it,
          though  the  MIME  code is new and has not been heavily used
          yet.


          Domain names


               Pine needs to know the full host and domain name of the
          site it is running on.

          (Domain names are a feature of the Internet and are used  to
          uniquely  name each host on the network. A domain name has a


                                     - 6 -

                            - Pine Technical Notes -


          number of parts separated by periods. Each part represents a
          level in the hierarchy. An example of a name is

                    "olive.cac.washington.edu"

          In this name the top level is "edu", indicating it  is  part
          of an educational institution; the second level is "washing-
          ton" indicating the University of  Washington;  "cac"  is  a
          specific  department;  and  "olive" is the hostname. The top
          level names are  assigned  by  Internet  organizations,  and
          other  names  are  assigned  at  the appropriate level.  The
          Domain Name Service, DNS, or named on UNIX  systems  is  the
          distributed  data base used to look up these names. The file
          /etc/hosts usually sets the name of the local host.  If  you
          are  not  on  the Internet or other network you can probably
          just use a single part hostname)


               Pine determines the domain name it uses as follows.  If
          no   settings   are   made   in  the  users  .pinerc  or  in
          /usr/local/lib/pine.conf then it uses the domain name looked
          up  from  the  system. This usually comes out of /etc/hosts,
          DNS or  the  local  configuration  data  base  (e.g.  Yellow
          Pages).  If  this  look up fails and there are no other set-
          tings Pine will exit with the error message "No host name or
          domain name set."

          Often it happens that the domain name that  Pine  gets  from
          the  hostname  lookup is not the fully qualified domain name
          because of the way the /etc/hosts file is set up. When  this
          occurs Pine cannot fully qualify the addresses it sends out.
          It isn't essential that the name be fully qualified, but  it
          is  highly  desirable because it can avoid some mail routing
          problems. In some cases  sendmail  will  fully  qualify  the
          addresses  as  it's  delivering  the mail. Specifically, the
          problem is because the entry in  /etc/hosts  for  the  local
          system  has  the unqualified name first and the fully quali-
          fied name following as an alias as follows:

              128.95.112.99   olive.cac.washington.edu   olive

                          is preferred over

              128.95.112.99   olive   olive.cac.washington.edu



               The domain name may be set explicitly with  the  "user-
          domain"   variable   in   either   the   user   .pinerc   or
          /usr/local/lib/pine.conf. If set in /usr/local/lib/pine.conf
          it  affects all Pine users on the system. This setting over-
          rides the system setting.



                                     - 7 -

                            - Pine Technical Notes -


               At the University of Washington an effort has been made
          to encourage host-less addresses so that users may move from
          one host to another without changing there e-mail addresses.
          This  usually  requires some sort of data base at the domain
          level to direct the mail to a particular host. In place of a
          data base, all mail could be directed at one host. To facil-
          itate this you can set the "use-only-domain-name" to  "yes",
          and Pine will strip off the host part of the address. In the
          example   above,   the   host-less    address    would    be
          "cac.washington.edu".   This stripping is achieved by remov-
          ing the first part of what is assumed to be the  full  host-
          name.  The  removal  of the host part is only applied to the
          full hostname looked up from the system and not to  the  one
          set by the "user-domain" variable.


               Once the domain name is determined, Pine  uses  it  for
          qualifying  all  unqualified  outgoing  addresses and in the
          From: in outgoing mail.  It is also used to determine if  an
          address is that of the current Pine user. The full host name
          is also used in the internal message ID.




          Pine Configuration (system wide and per user)


               There are two configuration files in Pine:  the  system
          wide  configuration  file, /usr/local/lib/pine.conf; and the
          per user configuration file,  .pinerc  in  each  users  home
          directory. The syntax of the variables or options in them is
          the same. In a number of cases the variables  are  the  same
          too. The syntax is:

              <variable> = <value>

          If the value is absent then the variable is unset. To set  a
          variable  to the empty value the syntax is "". Quotes may be
          used around any value.  All values are strings  and  end  at
          the  new  line  or  the closing quote.  Leading and trailing
          space is ignore unless it is included  in  the  quotes.  For
          some  variables  the  only  appropriate values are "yes" and
          "no". If a variable is set in the system configuration  file
          and  the  per  user configuration file, the per user setting
          takes precedence. If a local variable is unset (usually  the
          case  for  most  variables) the system value is used. If the
          system value is unset then the compiled in default value  is
          used.


               Both files may contain comments which are lines  begin-
          ning  with  a  "#".   You may get a sample/fresh copy of the


                                     - 8 -

                            - Pine Technical Notes -


          system configuration  file  by  running  "pine  -conf".  The
          result  will be printed on the standard output with comments
          describing each variable. All  the  possible  variables  are
          included  in  this.  The best thing to do is create the file
          initially with this command and then edit in the values  you
          want to set. Pine will run fine without this file.


               References  to  UNIX  environment  variables   may   be
          included  in  the  pine  configuration  file.  The format is
          "$variable" or "${variable}".  The  character  "~"  will  be
          expanded to the $HOME environment variable.


               Pine will automatically create  the  per  user  .pinerc
          file  the  first  time  it is run. It will write entries for
          each variable with comments so one knows what all the possi-
          ble  variables  are  by just looking in the file. Pine reads
          and writes  the  .pinerc  file  occasionally  during  normal
          operation  as  state,  like  the  printer  configuration, is
          changed. Any comments or additional lines in the  file  will
          be carried along as the file is rewritten. This will guaran-
          tee backward compatibility with old versions  as  new  vari-
          ables  are  added  to  subsequent  versions of Pine. It also
          allows the user to put additional comments in  the  .pinerc.
          Pine  always  writes this file at least once when running so
          you can tell when a user last invoked Pine by  the  date  on
          this  file.  This is how the pine-use program (which you can
          compile and use) counts up the current Pine users.


               Currently, most of these variables have to  be  set  by
          hand  with  an  editor.  Eventually it would be nice if Pine
          had a user interface to set these  variables  so  the  users
          don't  have to venture out with a text editor. It's intended
          that only experienced users make settings with  the  current
          scheme.

          Descriptions of the variables:


          user-id
               This is disabled for time sharing machines, but may  be
               used on versions for PCs.


          personal-name
               Your full personal name. Normally this  is  taken  from
               the  accounts  data  base (/etc/passwd) on most systems
               and doesn't need to be set, but you can over  ride  the
               systems  idea  of  who  you are with this. This is only
               appropriate in the user .pinerc



                                     - 9 -

                            - Pine Technical Notes -


          printer
               This is the current setting for a users  printer.  It's
               usually  the  same  value  as the standard-printer, the
               personal-print-command or "attached-to-ansi". The value
               of  this in the system configuration file specifies the
               default value if users don't set their own. The setting
               of  this  variable  is  done  by  the printer selection
               screen in Pine.


          standard-printer
               Specifies the command for printer selection number 2 on
               the printer menu. This is only in the system configura-
               tion file.


          personal-print-command
               Only in the per user configuration. This corresponds to
               item  3  in the printer menu. This variable retains the
               personal-print-command when the printer is set to some-
               thing other than item 3.


          last-time-prune-questioned
               Despite it's silly  name,  this  variable  records  the
               month  the user was last asked if his sent-mail folders
               should be pruned. The format is yy.mm. This is automat-
               ically  updated by Pine when the the pruning is done or
               declined. This is only in the per user configuration.


          user-domain
               Sets the domain or host name for the  user,  overriding
               the  system  host  or  domain name. See the domain name
               section. This can be set for the whole system  and  for
               each user.


          use-only-domain-name
               Can be set to "yes" or "no". At this point anything but
               "yes"  means  "no",  except when it is unset. If set to
               yes one part of the hostname will be lopped off to  get
               the  domain  name  and the domain name will be used for
               outgoing mail and such. That is,  if  the  hostname  is
               "milton.u.washington.edu"  and  this variable is set to
               "yes", then "u.washington.edu" will be used on outgoing
               mail.  This  can  be  set  for the whole system and per
               user.


          inbox-path
               This specifies the name of the folder to  use  for  the
               inbox.  Normally  this is unset so the system's default


                                     - 10 -

                            - Pine Technical Notes -


               is used. The most common setting of this is to open  an
               IMAP    mailbox    for    the    inbox.   For   example
               "{marge.cac.washington.edu}inbox" will open the  user's
               standard  inbox  on the mail server, marge. This can be
               set per user and for the whole system.


          elm-style-save
               Setting this to  "yes"  will  cause  Pine  to  generate
               default  folder  names  when saving messages similar to
               the way elm does. The folder  will  be  named  for  the
               username  of the sender of the message. This can be set
               per user and for the whole system.


          header-in-reply
               This governs whether or not the header of the  original
               message is included when including the original text of
               a message in a reply.  This can be set per user and for
               the whole system.


          default-fcc
               The name of the folder to which all outgoing mail  goes
               is set here. The compiled-in default is "sent-mail". It
               can be set to "" to turn off saving copies of  outgoing
               mail and can be set on a per user or system wide basis.


          bugs-nickname, bugs-fullname and bugs-address
               These can only be set for the whole system  and  speci-
               fies  an  entry  for  the  address  book that is always
               inserted if found absent.  It  is  a  way  to  put  the
               address  to  send  requests  for  help to in everyone's
               address book so users can find it easily.


          smtp-server
               When this variable is set to a host name or IP  address
               Pine  will  try to drop off outgoing mail to the speci-
               fied host via SMTP instead of sending it by passing  it
               off to sendmail.


          editor
               Sets the name of the  alternate  editor  for  composing
               mail. It will be invoked with the "^_" command.


          image-viewer
               This variable names the program to call for  displaying
               parts  of a MIME messages that are of type image. It is
               usually set to xloadimage or xv. In a future version of


                                     - 11 -

                            - Pine Technical Notes -


               Pine  this  configuration  will be replaced by the more
               general "mailcap".



          feature-level
               This controls the user level for Pine. It may be set to
               "seedling" for novice users, "sapling" for intermediate
               users and "old-growth" for advanced users. In Pine  3.0
               there  is  no  difference  between seedling and sapling
               modes, and old-growth just adds the "H" command to view
               the full header and allows the "^_" command in the com-
               poser to invoke an alternate editor.


          old-style-reply
               Setting this to  "yes"  will  cause  the  signature  to
               appear  at  the end of the original, included text in a
               reply instead of at the beginning. See details  in  the
               section on replying and signatures.


          signature-file
               Names the file to be included as  the  signature.  This
               defaults to ".signature".


          mail-directory
               Use this to change the subdirectory that Pine puts  its
               mail files in.  The default is "mail".


          character-set
               This sets the  character  set  used  by  the  terminal.
               Currently  appropriate  values  are  US-ASCII  and ISO-
               8859-1 through ISO-8859-9. See the section on character
               sets for more details. The default is US-ASCII.


          show-all-characters
               If this is set to yes, Pine will display all 8 bits  of
               any text received, regardless of whether it matches the
               character set currently in use.


          new-version
               If this is on, a message explaining that this is a  new
               version  of Pine will be given. In Pine 3.02 this is on
               by default and should be set to "no" to turn  off  this
               message.





                                     - 12 -

                            - Pine Technical Notes -


          Mail folder reading, writing, locking and check pointing


               All mail files (folders) are read and  written  by  the
          c-client library. Extensive effort has gone into making this
          as robust as possible. The c-client provides locking against
          several  user  having  a  mail  file  open at once.  This is
          beyond the usual UNIX locking which just guarantees that two
          processes  won't  write  the  file  at the same time and are
          known as "MRC" locks, named after Mark Crispin.  The  second
          user  that attempts to open the folder with Pine will get it
          opened read-only.  Because there is generally no such  lock-
          ing  convention on UNIX platforms this additional locking is
          only effective  against  multiple  uses  of  Pine  or  other
          mailers using the c-client such as MailManager, ms and a few
          others. Berkeley mail(1), elm, mh and such will be  able  to
          open  the  mail  folder  when Pine has it open.  If the mail
          file changes on the disk underneath Pine  or  the  c-client,
          they  will  give up on the mail file and close it. Pine also
          checkpoints the mail file every so often  depending  on  how
          many  changes  have been made and how long it has been since
          the last change. This minimizes the potential for loss.


               With Berkeley format mail files, there are three modif-
          ication  operations done to mail folders: appending new mes-
          sages, rewriting the file to delete messages  and  rewriting
          to  changes  status  flags.  Appending messages is a special
          case and doesn't threaten the integrity of the mail  already
          in  the  file. If an append can't be completed for some rea-
          son, such as a full disk, the whole append  is  aborted  and
          the  mail file left as is. When rewriting the mail file more
          care has to be taken. What the c-client, and therefore Pine,
          does is first calculate how much the mail file would grow if
          all the status flags were inserted in  their  longest  form.
          Then the mail file is extended by that amount, writing nulls
          past the end of the file to be sure there's room on the disk
          and  to reserve the space. If the extend was successful, the
          mail file is rewritten over the existing data without  trun-
          cating  the file. This is to make sure the disk space origi-
          nally occupied by the mail file is not consumed by some  run
          away disk-block-eating process.


               The extended locking works by creating  lock  files  in
          /tmp  of  the  form  ".\usr\spool\mail\joe". Flock() is then
          used on these files; their existence does not  constitute  a
          lock.  This  lock  is  created when the folder is opened and
          destroyed when it is closed. When  the  folder  is  actually
          being  written the standard Berkeley locks are also created.
          One could say the Berkeley  locks  are  created  within  the
          other  locks.   This  way  new mail can be delivered into an
          open folder.


                                     - 13 -

                            - Pine Technical Notes -


               If a mail file is modified underneath of Pine while  it
          has it open, Pine will give up on that mail file, concluding
          it's best not to do any further reads or  writes.  This  can
          happen  if  another mailer that doesn't obey MRC locks (e.g.
          elm, or mail) is run while Pine has the mail folder open.


               Pine can read and write mail files via NFS, but IMAP is
          preferred.   Some modifications have been made to the way it
          operates on the mail files to make things work  better  with
          NFS,  but  they are not guaranteed to work with all versions
          of NFS or as reliable as writing to a standard file  system.
          See the NFS section for more details.


          Terminals and Termcap


               Pine has been designed to require as little as possible
          from  the terminal. It uses termcap or terminfo depending on
          how it was compiled. At the  minimum  Pine  requires  cursor
          positioning,  clear to end of line and inverse video. Unfor-
          tunately there are terminals that are missing some of  these
          such  as a vt52. Pine makes no assumptions as to whether the
          terminal wraps or doesn't wrap. If the  terminal  has  other
          capabilities  it will use them. Pine won't run well on older
          terminals that require a space on the screen to change video
          attributes  such  as  the  Televideo 925. One can get around
          this on some terminals by using "protected field" mode.  The
          terminal  can  be made to go into protected mode for reverse
          video, and then reverse video is assigned to protected mode.


               Pine handles screens of most any size and  resizing  on
          the fly. It catches SIGWINCH and does the appropriate thing.
          A screen one line high will display only the new mail notif-
          ication.  Screens  that are less than ten columns wide don't
          format very nicely or work  well,  but  will  function  fine
          again  once resized to something large. There is an internal
          maximum screen size, currently 170 columns by 200  rows.  If
          the  screen  is  made bigger than it, the whole screen won't
          all be used.  These maximum values are set in  os-xxx.h  and
          can  be  changed,  but  increasing them will increase memory
          usage.


          Memory Usage


               The current Pine/C-client architecture isn't  the  most
          efficient  in  it's  memory  use. It reads in the whole mail
          folder as it's parsing it.  It also makes  in-memory  copies
          of  messages  as  they  are forwarded, saved and such, so it


                                     - 14 -

                            - Pine Technical Notes -


          doesn't operate very efficiently on messages over  1Mb,  but
          normal  operation  is OK. Some work has been done already to
          ameliorate the situation and more is possible.


          Sendmail, SMTP and mail delivery


               Pine submits outgoing mail either to sendmail or to  an
          SMTP  server  for  delivery.  When using sendmail, it writes
          the message to a temporary file in /tmp.   Then  it  runs  a
          shell  in  the background that runs sendmail on the file and
          removes the file. It's done with a shell in  the  background
          so  the  user  doesn't  have to wait for sendmail to finish.
          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 mail back; and the "-oi" flag  to
          ignore  dots  in  incoming  messages.  (The dots are used to
          indicate things such as the end of the message).


               To make Pine operate as an SMTP client, the smtp-server
          variable  can  be  set  to the IP address or hostname of the
          SMTP server. When a message is sent Pine will post the  mes-
          sage  directly to the SMTP server. This is particularly use-
          ful with Pine running on UNIX workstations with IMAP because
          it saves having to configure sendmail on the workstation. It
          is also essential for the DOS  version  since  there  is  no
          alternative to SMTP.



          The Berkeley Mail file format and locking


               Here are the grungy details on how  the  Berkeley  mail
          file  format works. This format comes to us from the ancient
          UNIX mail program, /bin/mail. This program was actually used
          to interactively read mail at one time, and is still used on
          some systems as the local delivery agent.  The  messages  in
          the file are separated by lines of the following format:

          "From user-name WWW MMM DD HH:MM:SS YYYY\n"

          "User-name" is from the envelope and the date is as  printed
          out by ctime(). This separator must be at the beginning of a
          line and should have a blank line before it. The  mail  file
          usually ends in "0. Because of the format of the separators,
          no lines in the mail message can begin with "From  ",  space
          included,  so  they  are modified to be ">From ". You'll see
          this occasionally in mail messages. The date is the date the
          message  was  first  received and should be carried along if
          the message is copied to  another  folder.  This  format  is


                                     - 15 -

                            - Pine Technical Notes -


          antiquated and should be replaced!


               There are two kinds of locking that are commonly  done.
          The older form creates a "xxxx.lock" file in /usr/spool/mail
          to lock the mail box "xxxx". This makes use of the fact  the
          directory  operations  are  atomic  in  UNIX. It also mostly
          works across NFS. There  are  involved  algorithms  used  to
          determine  if  a lock is held and should be broken.  Usually
          the calculation takes into account the load on the system.


               The other locking scheme uses the flock()  system  call
          on  the  mail box. This is much more efficient and the locks
          can't get stuck because they go away when the  process  that
          created  them  dies.  This  is  usually  found on 4.3bsd and
          related machines.


               These locks only control actual reading and writing  to
          the  file.  When  new  mail is being delivered, messages are
          being deleted or status being updated these locks are  used.
          For  small  mail  files they should never be around for more
          than a few seconds. This is normally the only  locking  used
          for mail on UNIX mail system. The c-client/Pine extends this
          locking to prevent multiple mail readers  from  opening  the
          same  mail folder for modification twice. See the section on
          "Reading, Writing, Checkpointing and Locking".


          Accessing mail folders via NFS

               It is possible to access NFS mounted mail folders  with
          Pine,  but  there  are  some drawbacks to doing this. One is
          that the per folder "MRC" locks don't work because  /tmp  is
          usually not shared, and even if it was, flock() doesn't work
          across NFS. This is the lock added by Pine and not the stan-
          dard UNIX mail file lock against writing.

               The implementation of the standard  UNIX  ".lock"  file
          locking has been modified to work with NFS as follows. Stan-
          dard hitching post locking is used: First a  uniquely  named
          file      is     created.     Usually     something     like
          "inbox.host.time.pid". Then a link to it  is  created  named
          "inbox.lock" where the folder being locked is "inbox".  This
          file constitutes the lock. This is a standard  UNIX  locking
          scheme.  It works because the link(2) system call is atomic.
          With NFS, link(2) is still  guaranteed  to  be  atomic,  but
          packets can get lost and cause problems. The worst case hap-
          pens when the link request makes it to the  server  and  the
          link  is  actually  made  on the server, but the acknowledge
          packet gets lost.  The  client  then  retransmits  the  link
          request.  When  it arrives at the server, the server doesn't


                                     - 16 -

                            - Pine Technical Notes -


          know it's not a new request (NFS is stateless)  and  returns
          saying  the link already exists, so the whole link operation
          fails. The mail software will conclude the mailbox is locked
          and that it should wait.

               This has been worked around by ignoring the return code
          from  link(2).  After the link returns, a stat(2) is done on
          the file. If the file has two links, it  is  concluded  that
          the lock succeeded and it is safe to proceed.


               Another problem occurs with data caching. On  many  NFS
          implementations  the client will never see new data appended
          to a file if the file is held open. Even a stat on the  file
          will  not  reveal  the  new  file size or modification time.
          This is quite  different  from  standard  UNIX  file  system
          semantics.  To get around this, the c-client library reopens
          the file every time it checks for new mail.


               One last annoyance that hasn't been solved happens when
          the  c-client  detects  a change in the modification time of
          the mail file, but no change in the  size  of  the  file.  A
          warning message is given to the user (which usually confuses
          the users). Thus far this has only been an annoyance and not
          actual problems with the mail file have been found.


               In conclusion, it is mostly safe  to  access  mail  via
          NFS.  The  main  problem  will  occur  when two users try to
          access the same mail folder from different hosts.  When  the
          second  user  writes  the file, Pine will get upset that the
          file has been changed underneath of it and abort  operations
          on  the  folder. Pine will continue to display mail from the
          folder that it has in its internal cache, but  it  will  not
          read nor write any further data. The only thing that will be
          lost out of the first session when this happens is the  last
          few deletion marks since the last checkpoint.


          MIME -- Multipart Internet Mail Extensions


               Using the MIME standard, Pine is able to  attach  arbi-
          trary  files  to mail messages. These files can be binaries,
          executables, spreadsheets, GIF, binhex, text  files  or  any
          other  sort.  The  receiver  of  the message will be able to
          detach the file exactly as it was sent.  MIME  messages  may
          also  include  sounds,  images  and  even video. Pine cannot
          display most of these formats, but  it  will  identify  each
          part  or  attachment  and  allow  that part to be saved in a
          file.



                                     - 17 -

                            - Pine Technical Notes -


               As of these notes for Pine 3.0,  MIME  is  a  very  new
          standard  and  Pine  is  one of the early implementations of
          MIME, thus many conventions aren't clear and we  have  prob-
          ably made some big mistakes. MIME is defined in RFC-1341 and
          is very soon expected to be accepted by the  Internet  agen-
          cies  as  an  Internet  standard. There are many other folks
          working on MIME implementations and we expect that it's  use
          will  become widespread on the Internet.  Generally, MIME is
          a way of encoding, in ASCII, a multipart message  structure.
          The parts may be nested and may be of seven different types:
          Text, Audio, Image, Video,  Message,  Application  and  Mul-
          tipart  (nested).  Provisions  are included for encoding any
          binary data in ASCII in a base 64 format similar to uuencode
          or  btoa.  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 char-
          acter sets. It also provides a simple "rich text" format for
          marking  text  as  bold,  underlined  and  such.  There is a
          mechanism for splitting messages  into  multiple  parts  and
          reassembling them at the receiving end.


               Pine is able to view and/or take apart just  about  any
          MIME message. It will display a list of all the parts, their
          types and sizes. All text parts will be shown unless  it  is
          not possible because of the character set. Rich text will be
          displayed in a very limited  way  (it  will  show  bold  and
          underlining).  Pine cannot play audio messages at all (yet),
          nor display video.  Image parts can be passed off to a  pro-
          gram  such  as  xloadimage to be viewed. Pine checks for the
          DISPLAY variable indicating it is running on an  X-terminal.
          Pine  will also display message and multipart types.  If the
          parts of a multipart message are alternate versions  of  the
          same thing Pine will select and display the one best suited.
          For parts  of  type  message/external-body,  the  parameters
          showing  the retrieval method will be displayed. Messages of
          type message/partial  cannot  currently  be  reassembled  or
          sent.  Lastly, Pine cannot display the application type, but
          works well saving parts of type application/octet stream  to
          files. (These are listed as type "file").  Any message part,
          regardless of type, can be saved to a file.


               The main focus of the MIME in Pine has been to  provide
          attachments   thus,  Pine  mainly  generates  messages  with
          application/octet-stream parts along with the text parts. As
          a bit of a bonus, Pine will recognize GIF files and tag them
          as images so they can be displayed on  X-terminals  as  men-
          tioned  above.  When  a file is attached to Pine the file is
          read and evaluated as to whether it is  ASCII  text,  8  bit
          text or binary.  If a file any lines longer than 500 charac-
          ters in it or more than 10% of the characters 8 bit it  will
          be considered binary. If the files has some 8 bit characters


                                     - 18 -

                            - Pine Technical Notes -


          in it will be considered 8 bit text, otherwise  it  will  be
          considered  plain text. The first part of any multipart mes-
          sage generated in Pine will always be text  with  the  other
          parts following.


               MIME has two ways of encoding 8 bit, or  non-text  data
          known  as  quoted  printable  and  base64.  Quoted printable
          leaves most of the text alone and only  changes  the  8  bit
          characters  to  "="  followed by the hex digits. For example
          "=09" is a tab. It has the advantage that it is mostly read-
          able  and that it allows for end of line conversions between
          unlike systems. Base64 encoding is similar  to  uuencode  or
          btoa  and just encodes a raw bit stream. These encodings are
          designed to get text and binary files through even the  most
          improperly implemented and configured gateways intact.


               Multipart messages can be  forwarded  and  included  in
          replies. How to do this with multimedia mail on a plain text
          device was not completely clear, so  some  improvements  are
          possible.  In  both  cases the parts of the original message
          will be included after some text. If the first part  of  the
          message was text you will be able to edit this text.  If the
          first part of the original was not text  a  new  blank  text
          part  will be added. At present Pine has trouble with multi-
          ply nested multipart messages and is unable  to  forward  or
          reply  to  them.  A  nested multipart message with a part of
          type message in between will be handled correctly.  Messages
          can  be  forwarded as MIME attachments rather than just text
          when running in old-growth mode. When this is done the  ori-
          ginal  message is included with all it headers and cannot be
          edited.  The receiver will only see the filtered  header  as
          Pine filters the headers of sub-messages.


               When a user of a non-MIME mailer receives  a  multipart
          MIME messages it will look something like this:

              Date: Tue, 14 Jul 1992 17:55:17 -0700 (PDT)
              From: Laurence Lundblade <lgl@cac.washington.edu>
              Subject: Test MIME message
              To: Laurence Lundblade <lgl@cac.washington.edu>

              --16820115-1435684063-711161753:#2306
              Content-Type: TEXT/PLAIN; charset=US-ASCII

              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. It has been shortened for this example. The
              Base 64 stuff looks dorky in PostScript because
              troff -me doesn't have a fixed font like courier.


                                     - 19 -

                            - Pine Technical Notes -


              Laurence Lundblade                       206-543-5617
                lgl@cac.washington.edu
                   Computing and Communications, University of Washington

              --16820115-1435684063-711161753:#2306
              Content-Type: APPLICATION/octet-stream; name=login
              Content-Transfer-Encoding: BASE64
              Content-Description: NeXT login program

              AYAAAABAAAAAQAAAAQAAAL4AAAAAQAAAAEAAAJYAAAAAAAAAAAA
              AAAAAAAABfsAAADFAAAFswAAAAHAAAABwAAAAgAAAAAX190ZXh0
              AAAAF9fVEVYVAAAAAAAAAAAAAAAAAAAAAAQpAAAAxQAAAABAAAA
              AAAAAAAAAAAAABfX2Z2bWxpYl9pbml0MAAAX19URVhUAAAAAAAA
              KQAAAEwAAATuAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAF9fZnZt
              XQxAABfX1RFWFQAAAAAAAAAAAAAAAAR1AAAAAAAABToAAAAAgAA
              AAAAAAAAAAAAAAAX19jc3RyaW5nAAAAAAAAAF9fVEVYVAAAAAAA
              BHUAAADQQAAFOgAAAAAAAAAAAAAAAAAAAACAAAAAAAAAABfX2Nv
              AAAAAAAX19URVhUAAAAAAAAAAAAAAAAFRgAAACsAAAYLAAAAAIA
              AAAAAAAAAAAAAAAAF9fZGF0YQAAAAAAAAAAAABfX0RBVEEAAAAA
              AAVxAAAAQgAABjYAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAX19i
              AAAAAAAAF9fREFUQQAAAAAAAAAAAAAAABbMAAAADAAAAAAAAAAC
              AAAAAABAAAAAAAAAABfX2NvbW1vbgAAAAAAAAAAX19EQVRBAAAA
              CAlcwAlZCBMT0dJTiBGQUlMVVJFJXMgT04gJXMsICVzAHN1AGxv
              Wxsb2Mgb3V0IG9mIG1lbW9yeQoAJXMgdG9vIGxvbmcNCgAvZXRj
              3Vzci9hZG0vd3RtcAAAAABAKCMpUFJPR1JBTTpsb2dpbiAgUFJP
              WRzLTQyICBERVZFTE9QRVI6cm9vdCAgQlVJTFQ6U3VuIE5vdiAx
              zoyMSBQU1QgMTk5MAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
              AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
              AAAAAAAAAAAAAAAAAAAAAAAAAAAQCgjKSBDb3B5cmlnaHQgKGMp
              DE5ODcsIDE5ODggVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNp
              2FsaWZvcm5pYS4KIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgBAKCMp
              wk1LjQwIChCZXJrZWxleSkgNS85Lzg5AAAAABHUAAAR1f//////
              wAAEdQAABHUAAAR1AAAEdQAAAEsAxwREwT/GhkSDxcWAAAR2gAA
              AAR5gAAEeoAABHuAAAR8gAAEfYAABH6AAAR/gAAEgIAABIGAAAA
              AAB

              --16820115-1435684063-711161753:#2306--



          International Character Sets


               Pine will pass ISO-2022 escapes  sequences,  though  it
          will  not read the escape character on input (yet). There is
          a compiled in list of about 20  of  these  escape  sequences
          that  are  passed. Other sequences with the Escape character
          will not be passed. The width of these escape  sequences  is
          taken  into  account when displaying the text on the screen.
          ISO-2022 escape sequences are passed regardless of the  type
          of text as tagged by the MIME formatting




                                     - 20 -

                            - Pine Technical Notes -


               Pine can display  most  character  sets  in  ISO-8859-1
          through ISO-8859-9 as well as US-ASCII, the default. Rather,
          Pine doesn't actually display the characters but passes them
          through;  it  is up to the actual display device to show the
          characters correctly. For example you will need some special
          terminal  that  can  display Arabic to show ISO-8859-6 text.
          The character sets are:

              US-ASCII        Standard 7 bit English characters
              ISO-88590-1     8 bit European "latin 1" character set
              ISO-88590-2     8 bit European "latin 2" character set
              ISO-88590-3     8 bit European "latin 3" character set
              ISO-88590-4     8 bit European "latin 4" character set
              ISO-88590-5     8 bit Cyrillic
              ISO-88590-6     8 bit Arabic
              ISO-88590-7     8 bit Greek
              ISO-88590-8     8 bit European "latin 5"" character set
              ISO-88590-9     8 bit Hebrew


          In all of these, the lower 7 bits are the same as US-ASCII.


                Pine makes use of the character  set  tags  associated
          with  text  in MIME to decide if text is displayable or not.
          To make use of these character sets in Pine  the  character-
          set variable should be set to match the display or terminal.
          Most fonts on X-terminals today are ISO-8859-1. When  e-mail
          arrives,  the  character set of the mail is checked and com-
          pared to the setting of the character-set  variable.  If  it
          matches, the text is displayed. If it is determined that not
          all the character can be displayed, the  ones  that  can  be
          will  be,  and  the ones that can't will be replaced by "_".
          For example if a French message arrives in ISO-8859-1  on  a
          display  that shows US-ASCII, the US-ASCII character will be
          displayed. One may set show-all-characters in the .pinerc to
          "yes" and all text will be displayed regardless of character
          set.


               When mail is sent, Pine tags the outgoing text with the
          appropriate  character  set. The character set it determined
          by the character-set variable. If the character set  is  one
          of  the ISO-8859 character sets and there are no 8 bit char-
          acters entered the tag assigned will be US-ASCII.




                       Section II -- Functions/Reference





                                     - 21 -

                            - Pine Technical Notes -


          Command Line Arguments

          There are a few command line arguments.  The  order  is  not
          important:


          -i           Go directly to the Mail  Index,  bypassing  the
                       main menu.

          -sort <type> Specify the default sort  order  for  the  main
                       index.  The  type  may  be  one  of: "subject",
                       "from", "size", "arrival", or "date". "Reverse"
                       may be added along with any of these types.

          -z           Enable ^Z Berkeley style job  control.  The  is
                       normally  off  because  it's not something that
                       naive users may understand

          -d <n>       Turn on debugging at level <n> where level  <n>
                       is  between  1 and 9.  The output is written to
                       the .pine-debugX files. Levels 8 and 9 turn  of
                       cushioning  of  aborts like bus errors and seg-
                       mentation fault

          -k           Turn on function key mode.

          -r           Go  into  restricted  demo  mode.  Saving   and
                       exporting  messages is not allowed and mail can
                       only be addresses to oneself.

          -conf        Print out a sample/fresh system wide configura-
                       tion file on the standard output. This is *not*
                       the same as per user  .pinerc.  They  have  the
                       same syntax and some of the same variables, but
                       they do have differences.

          -f <folder>  Opens the named folder as Pine starts  up.  The
                       folder  name  is  a  path relative to the users
                       "mail" subdirectory.

          -h           Provides a list, like this  one,  of  arguments
                       that can be given to Pine.

          -nr          Goes into "anonymous news readonly" mode.  This
                       is  mostly  for a particular use at the Univer-
                       sity of Washington. Pine behaves  appropriately
                       for  an  unidentified  user  to  read news, for
                       example at a public information  terminal.  The
                       set  of  commands  is  greatly  limited  and no
                       updates to the news  file  status  is  allowed.
                       This  is  usually used with both the -f and the
                       i- flags.



                                     - 22 -

                            - Pine Technical Notes -




          Address Book


               The address book is stored in the user's home directory
          in the file ".addressbook". The lines are of the format:

                        <nickname>TAB<fullname>TAB<address>

          If the entry is an address list then  <address>  is  of  the
          format:

                        (<address>,<address>,<address>,......)

            Normally entries are one per line unless it is a list  and
          then  the  entry  extends  until the closing parenthesis. If
          lines are encountered in the address book that don't fit the
          format, those that don't have two tabs, they are ignored. An
          older format is also supported where the address lists don't
          have parenthesis. Spaces are not allowed in nick names.


               Entries in the address book may refer to other  entries
          in  the  address  book.  Lists  may be infinitely nested. If
          addresses refer to each other in a loop this is detected and
          flagged.  The  address will be changed to "**** address loop
          ****".


               This file is rewritten by Pine frequently in the format
          it  thinks proper so comments or other formatting introduced
          with a text editor or other  will  not  be  maintained.  For
          example,  if  you copy some bizarre file to .addressbook and
          run Pine you're likely to find the file mostly empty as Pine
          will only write back what it understands from the file.


               There is a shell script, brk2pine.sh, that can  convert
          Berkeley  style  personal  aliases  in .mailrc files to Pine
          address book format.  It reads the users .mailrc by  default
          or  takes  a  filename  as an argument and produces the Pine
          address book on the standard output. A good way for  a  user
          to run this is:

                        brk2pine.sh >> .addressbook

          This will append the entries in the .mailrc to the  address-
          book.   System  administrators  can  convert  someone else's
          aliases with:

                        brk2pine.sh  ~joe/.mailrc >> ~joe/.addressbook



                                     - 23 -

                            - Pine Technical Notes -


          You can look at the  shell  script  itself  for  the  grungy
          details

               The address book is kept sorted in order  by  the  full
          name  field. In order for this to be sensible the full names
          should be last name, then first name. Pine makes an  attempt
          to  encourage  use of this format and will reverse the order
          of any names that have a single comma in them when they  are
          in  addresses on outgoing mail so it will be formatted first
          then last. The T, Take, command that captures addresses  off
          incoming messages also attempts to reverse the name as it is
          inserted, though it doesn't always succeed. The way it works
          can probably be improved.


               When the address book is written out, it is first writ-
          ten  to  a temporary file and if that write is successful it
          is renamed to .addressbook to guard against  errors  writing
          the  file  that  might  destroy  the whole address book. The
          address book is written after each change.


               The Pine address book is intended to be personal rather
          than shared or global.  It's not a good way to run a mailing
          list. We decided not to use or invent a scheme for a  shared
          address  book  because it would only be usable by Pine users
          and we wanted to encourage interoperability. Pine use by one
          community  should  not  preclude  use  of  other tools. Some
          thought has gone into a "work group" which would allow shar-
          ing  of address books. A work group would have a leader that
          could set up the addresses and some members that  would  use
          it.  There  aren't  any plans to implement these "groupware"
          concepts though.


          Sent Mail Pruning

               Because the default behavior of Pine is to save a  copy
          of  each  outgoing message we thought it useful to encourage
          the users to periodically prune their sent-mail folder.  The
          first  time  a user invokes Pine each month it will offer to
          rename sent-mail to sent-mail-mmm-yyyy  and  then  offer  to
          delete all the old sent-mail-mmm-yyyy folders with an expla-
          nation of why it is offering to do so.  The user  will  only
          be  asked once a month and the month the user was last asked
          is recorded in  the  .pinerc  file.  If  the  user  has  set
          default_fcc  in  his  .pinerc to "" then no renaming will be
          offered.







                                     - 24 -

                            - Pine Technical Notes -


          Signatures and Reply/Forward formats


               The formatting of replies  and  forwarded  messages  is
          perhaps  a  matter of current style and personal taste. Pine
          encourages the user  to  put  his  contribution  before  the
          inclusion  of  the  original  text of the message being for-
          warded or replied to, though it does provide  an  option  to
          have  it put at the bottom. This is contrary to some conven-
          tions, but makes the  message  more  readable.   The  reader
          doesn't have to scroll through the original text that he has
          probably already been seen to find  the  new  text.  If  the
          reader  wishes  to  see  the  old message(s), the reader can
          scroll further into the message.


               When replying the user also has the option of including
          the  original  message.   The original message included in a
          reply is always preceded by a line like:

              On Tue, 14 Jan 1992, Ken Lowe wrote:



               The  header  of  the  original  message  is  optionally
          included  if  the  user  sets  "header-in-reply=yes"  in his
          .pinerc. Normally it is not included.


               If the file .signature exists it will  be  included  in
          outgoing messages.  It is included before composition starts
          so the user has a chance to edit it out  if  he  likes.  The
          signature is included at the beginning of the forwarded mes-
          sage or reply in order to keep it with the new text that  is
          being  added. If the filename .signature conflicts with sig-
          natures used with other mail or news programs, the file name
          read  for  the  signature  can  be  changed  by  setting the
          "signature-file" variable in the .pinerc.


               If "old-style-reply=yes" is  included  in  the  .pinerc
          then  the  signature will be appended to the end of the mes-
          sage after any included text.  This is the more conventional
          way of including signatures.


          Spelling checker


               Pine and Pico use the standard UNIX  spelling  checker.
          Lines  beginning with ">" (messages included in replies) are
          not checked. You may substitute a different spelling checker
          or use the usual, spell with arguments, by setting the SPELL


                                     - 25 -

                            - Pine Technical Notes -


          environment variable to the command to be executed. The mes-
          sage  text  to  be  checked is on the standard input and the
          incorrect words are expected on the standard output.


               Words  can  be  added  to  it's  dictionary.  Here's  a
          description  of  how it can be done on some versions of UNIX
          contributed by Bob Hurt.


               In case anyone besides me uses the Spell-checking func-
          tion  in Pine (Control-T) and has words highlighted that are
          "correct" (spelling is relative, IMO), here's how to include
          a list of non-standard issue words:



          Step 1:
               Make a file with all the words you want to  include  in
               your new dictionary.  I did mine with one word per line
               in alphabetical order.  Caps don't matter  at  all,  as
               far as I know.


          Step 2:
               At the UNIX prompt, type: "cat [word  file]  |  spellin
               /usr/dict/hlista  >  [new dict name]" where [word file]
               is the file you just created and [new dict name] is the
               name  of  the  new  dictionary  that  Pine will look at
               instead of the standard /usr/dict/hlista.  I  named  my
               word  file  .bobwords  and my dictionary .bobspell so I
               don't have to see them when I do  a  "ls"  command  (ls
               doesn't  list  "dot" files).  I also put the above com-
               mand into my .alias file as the command "makedict" so I
               can  add  a word to my word file and easily recreate my
               dictionary.  NOTE: the new dictionary is  in  something
               called a "hashed" format, and can't be read normally.


          Step 3:
               Check your new dictionary.  At the UNIX  prompt,  type:
               "cat [word file] | spellout [new dict name]" If you did
               everything correctly, it should just give  you  another
               prompt.   If  it  lists  any of the words in your file,
               something is wrong.  I can try and  help  if  all  else
               fails.


          Step 4:
               Now you have  to  tell  UNIX  to  use  your  dictionary
               instead  of the standard one by setting the environment
               variable SPELL to access your dictionary.  Go into your
               .login  or  .cshrc  file  in  your  root  directory (it


                                     - 26 -

                            - Pine Technical Notes -


               doesn't seem to make a difference which  one  you  use)
               and  add  the  line:  "setenv SPELL "spell -d [new dict
               name]"". I also created an alias for SPELL in my .alias
               file so I can use the UNIX spell command to spell-check
               a file outside of Pine.  (The  .alias  line  is:  alias
               spell 'spell -d [new dict name]')


          Step 5:
               Now you need to logoff and log back on to let UNIX look
               at  your  .login  (or .cshrc) file.  I think you can do
               this by typing: "source  .login"  at  the  UNIX  prompt
               instead  of logging out, but if Step 3 worked above and
               Pine fails, try logging out.  I'm  fuzzy  on  what  the
               command "source .login" does.


               That should do it.  Go into Pine and try it out.   Good
          luck.  Bob Hurt


          Postponing mail


               Composition of a half-done message may be postponed  to
          a  later  time.   Giving the ^O command in the composer does
          this. While a message is postponed, other  messages  can  be
          composed. When the user goes into compose while a message is
          postponed he will be asked if he wants to continue the post-
          poned  message. Only one message may be postponed at a time.
          We would like Pine to be able to have more  than  one  post-
          poned  messages, but haven't got around to it mostly because
          some work would have to be done to make the  user  interface
          nice. This is a good way to quickly reference other messages
          while composing.


               In Pine 3.0 there are some problems postponing messages
          that  have  MIME  components. Messages that have attachments
          that are local files can be postponed without any  problems.
          The  postponed  message  will  only store a reference to the
          file and not the actual file, so  the  file  should  not  be
          deleted  or  renamed  until  the  message is sent. Any other
          attachments will be dropped. These would have resulted  from
          forwarding  or  replying  to  a message with multiple parts.
          Eventually this will be fixed.


               Postponing messages that use 8 bit characters sets (and
          therefore quoted-printable encoding) does not work correctly
          either. The message will not be decoded upon  resumption  of
          the  composition leaving things like "=D6" in the file where
          the 8 bit characters where. Eventually this will be fixed.


                                     - 27 -

                            - Pine Technical Notes -


          Interrupted Mail


               If the user is composing mail  and  is  interrupted  by
          being  disconnected  (SIGHUP  or end of file on the standard
          input), Pine will save the interrupted composition and allow
          the user to continue it when he resumes Pine. A message will
          be given that an interrupted message can be continued as the
          user  starts  Pine.  The user should go into compose to con-
          tinue and will be asked if the interrupted message should be
          resumed.  To get rid of an interrupted message continue com-
          posing, going all the way into the composer, and then cancel
          the message with ^C.


          Printers and printing


               Pine can print to the standard UNIX line printers or to
          printers   attached  to  ANSI  terminals  using  the  escape
          sequences to turn the printer on and off.  The  user  has  a
          choice of three printers in the configuration.


               The first  setting,  "attached-to-ansi"  makes  use  of
          escape sequences on ANSI/VT100 terminals. It uses "<ESC>[5i"
          to begin directing all output sent to the  terminal  to  the
          printer  and  then "<ESC>[6i" to return to normal. Pine will
          send these escape sequences in "attached-to-ansi" mode. This
          also  works  with most ANSI/VT100 emulators on Macs and PC's
          such as kermit, NCSA telnet, VersaTerm Pro  and  WinQVT.  It
          has  come to be a popular feature, though sometimes generat-
          ing a lot of questions because the various emulators  imple-
          ment  the print feature differently. For example NCSA telnet
          requires "capfile = PRN" in the config.tel file. It  doesn't
          work  at  all  on  some others like the telnet provided with
          PC-NFS.


               The second selection is the standard  UNIX  print  com-
          mand.  The default here is "lpr", but it can be changed on a
          system    basis    to     anything     so     desired     in
          /usr/local/lib/pine.conf.


               The third selection is the users personal choice for  a
          UNIX print command. The text to be printed is piped into the
          command. Enscript or lpr with options are  popular  choices.
          The  actual  command  is  retained  even if one of the other
          print selections is used for a while.





                                     - 28 -

                            - Pine Technical Notes -


               A small C program, ansiprt.c, is included in  the  con-
          trib  directory. This is can be used to get Pine to print on
          PostScript printers in conjunction with enscript. Once  com-
          piled  and installed, ansiprt can be used in a print command
          like this:

              enscript -p - | ansiprt

          What ansiprt does, is read the standard input and  write  to
          /dev/tty.  This  is  needed  because Pine reads the standard
          output and error of the print command to present to the user
          as  the result of the print job. Ansiprt also sends the ANSI
          escape sequences to turn the printer on and off.


          Function Keys and Keymaps


               The standard Pine uses alphabetic keys  for  most  com-
          mands by default, and control keys in the composer.  Despite
          possible appearances the current bindings are the result  of
          much  discussion  and  thought.  (It's  very  unlikely we'll
          change them). Currently all the commands in the composer are
          single  control  characters. This keeps things very neat and
          simple for users. There are a few control  characters  left,
          and these are being reserved for commands to attach files to
          outgoing messages. Two character commands  in  the  composer
          are a possibility, but we're trying to avoid them because of
          the added complexity for the user.


               Control-S,  Control-Q,  Control-H  and  Control-\   are
          specifically  not  used  for commands. This is an attempt to
          avoid configuration and preempt some problems.  Control-H is
          treated  the  same  as  the  delete key so, the backspace or
          delete key always works  regardless  of  any  configuration.
          This  also  keeps  Pine  out  of  trouble  if  Control-S and
          Control-Q are used for flow control.


               Pine can also operate in a twelve function key mode. To
          go  into this mode invoke "pine -k" or "pinef". You can link
          or copy the "pine" executable to "pinef" to install "pinef".
          The  command menus at the bottom of the screen will show F1-
          F12  instead  of  the  alphabetic  commands.    The   escape
          sequences  for the function keys correspond to those used on
          PC's running a locally modified version of NCSA  telnet  and
          are similar to vt100 keypad keys.  They are:


                      ANSI/VT100      VT52
              F1:     <ESC>OP <ESC>=a
              F2:     <ESC>OQ <ESC>=b


                                     - 29 -

                            - Pine Technical Notes -


              F3:     <ESC>OR <ESC>=c
              F4:     <ESC>OS <ESC>=d
              F5:     <ESC>Op <ESC>=e
              F6:     <ESC>Oq <ESC>=f
              F7:     <ESC>Or <ESC>=g
              F8:     <ESC>Os <ESC>=h
              F9:     <ESC>Ot <ESC>=i
              F10:    <ESC>Ou <ESC>=j
              F11:    <ESC>Ov <ESC>=k
              F12:    <ESC>Ow <ESC>=l



               Pine has the escape sequences for a number  of  conven-
          tions  for arrow keys hard coded and does not use termcap to
          discover  them.  This  is  because  termcap   is   sometimes
          incorrect, and because many users have PC's running terminal
          emulators that don't conform exactly to what they  claim  to
          emulate.  Pine  also  traps escape sequences for a number of
          common function keys so user don't get an error  message  or
          have  an  unexpected  command executed for each character in
          the function keys escape sequence. Some arrow  keys  on  old
          terminals  send  single  control  characters like control-k.
          These arrow keys will not work with  Pine  (One  even  sends
          control-). The most common set is:


              Up:     <ESC>[A <ESC>?x <ESC>A  <ESC>OA
              Down:   <ESC>[B <ESC>?r <ESC>B  <ESC>OB
              Right:  <ESC>[C <ESC>?v <ESC>C  <ESC>OC
              Left:   <ESC>[D <ESC>?t <ESC>D  <ESC>OD



                It is possible to configure an NCD X-terminal so  some
          of   the  function  keys  operate.  The  following  are  the
          details...  Well, with Brad Greer's help, I have  been  suc-
          cessful  at  mapping  selected  keys  in  pine running in an
          xterm.  I thought you might be interested in how  it  worked
          for me.


          1    Start  up  pine  from  an  xterm,  also  specifying   a
               "resource name." This resource name will allow the user
               to specify resources for pine (that  deviate  from  the
               defaults).   -e.g.,  xterm  -name  Pine  -e pine & (the
               resource name "Pine" has a corresponding resource  sec-
               tion in the .Xdefaults file)


          2.   In my .Xdefaults file, I have the  following  "transla-
               tions", using lower hex values:



                                     - 30 -

                            - Pine Technical Notes -


                   Pine*VT100.Translations: #override 0
                   <Key>Delete:    string(0x04)
                   <Key>End:       string(0x05)
                   <Key>Escape:    string(0x03)
                   <Key>Home:      string(0x01)
                   <Key>Next:      string(0x16)
                   <Key>Prior:     string(0x19)
                   <Key>KP_Enter:  string(0x18)



               These seemed to be good candidates for remapping (i.e.,
          ease-of-use  &  similarity to existing mainstream software).
          Already, they have improved the  "quality"  of  my  life  in
          pine.


               One keymap I was not successful at was  the  action  of
          deleting  from  the  cursor  to the end-of-the-line (NOT the
          entire line as ^K does).  Often I only want to  delete  just
          part  of  a line, not the whole line. Any ideas? The program
          xedit works this way.  I'd appreciate any feedback  you  can
          provide.  I hope the above information proves helpful....
































                                     - 31 -

                            - Pine Technical Notes -



               The following is a rough keymap for most of Pine.


              KEY     MAIN    VIEW    FLDR    ADRBK   CMPSE   HDER
              A       AdrBk   Attach  Add     Add     |<-     |<-
              B                                       <-      <-
              C       Cmpse   Cmpse   Cncl    Cncl    Cncl    Cncl
              D               Delete  Delete  Delete  Delete  Delete
              E               Export          Edit    ->|     ->|
              F       Folders Forward                 ->      ->
              G               Go fldr Go fldr         Help    Help
              H                                       Bk spc  Bk spc
              I       Index   Index                   TAB     TAB
              J               Jump                    Justify
              K                                       Kill ln Kill ln
              L               Print   Print   Print   Redraw  Redraw
              M               Main    Main    Main    CR      CR
              N       News    Next                    Nxt ln  Nxt ln
              O       Other   Other   Open            Postpone
              P               Prev                    Prv ln  Prv ln
              Q       Quit    Quit                    ****    ****
              R               Reply   Rename          Rd file Rch hdr
              S               Save    Save    Crt Lst ****    ****
              T               Tk Addr         Add2lst 2 Spell 2 A bk
              U               Undelete                Un Del  Un Del
              V       View    View                    Scrll D
              W               Where   Where   Where   Where
              X               Expunge                 Send    Send
              Y                                       Scrll U
              Z               Sort                    Suspend Suspend
              [                                       ****    ****
                                                     ABORT   ABORT
              ]                                       Telnet  Telnet

              _
              ?               Help    Help    Help
              -               Prev pg Prev pg Prev pg
              SPACE           Next pg Next pg Next Pg Nxt wrd Nxt wrd




          New Mail Notification


               Pine checks for new mail every 30 seconds. It only  has
          to  check  the  time  stamp  on the mail file, so doing this
          doesn't place a load on the system. If you really don't want
          to wait you can force a new mail check by attempting to move
          the cursor off the end of the  message  index  three  times.
          It'll  beep  and  complain as you do this, but it will check
          for new mail on the third try.


                                     - 32 -

                            - Pine Technical Notes -


               When there is new mail, it will be shown in the  index,
          the  screen  will  beep and a message showing the sender and
          subject will be displayed. If there has been more  than  one
          new message since you last issued a command to Pine, it will
          show the count of new messages and the sender  of  the  last
          one.


               Other UNIX new mail notification methods work with dif-
          ferent degrees of success with Pine. Most expect the mail to
          be taken out of the /usr/spool/mail file and then file to be
          truncated.  Pine  leaves  it there so you can switch between
          different mailers unlike some  other  e-mail  programs  that
          copy all the mail to a private special-format file.


          biff:



          wnewmail:


          csh: If the mail variable is set in the csh  it  will  check
               for new mail periodically. It does this by checking the
               modification times on the /usr/spool/mail file. If  the
               access  time  is  less  than  the modification time and
               modification time and the access time are greater  than
               the  last  time  a  check  was made it prints "You have
               mail". The message will be "You have new mail"  if  the
               modification  time  is  greater  than the time the last
               command was executed.


               This doesn't work  perfectly  with  Pine  because  Pine
               modifies  the  mail file when it changes message status
               and expunges messages  leading  the  shell  to  believe
               there is new mail.


          login:
               The login program prints "You have mail"  if  there  is
               anything  in  /usr/spool/mail. With Pine this is always
               the case, so it will always give this message. On  most
               systems  it will say "You have new mail" if the modifi-
               cation time is later than the access time. Though  Pine
               rewrites  the  mail  file when it exists to delete mail
               messages and update status, it resets the  modification
               time to be earlier than the access time so this mechan-
               ism should work. When you have new mail login will  say
               so.




                                     - 33 -

                            - Pine Technical Notes -


          Mail folder checkpointing


               Periodically Pine will save the whole  mail  folder  to
          disk to prevent loss of any mail or mail status in case Pine
          gets interrupted, disconnected or  crashes.  The  period  of
          time Pine waits to do the checkpoint is carefully calculated
          to be minimally intrusive. The timing can be changed at com-
          pile  time  in  the os_xxx.h file and the delays are divided
          into levels


          Good Time:     This occurs when Pine has been idle for  more
                         than  30  seconds.  In  this  case  Pine will
                         checkpoint if 12 changes  to  the  file  have
                         been  made  or  at  least one change has been
                         made and a checkpoint hasn't been done for  5
                         minutes.


          Bad Time:      This occurs just after Pine has executed some
                         command. Pine will checkpoint if there are 36
                         outstanding changes to the mail  file  or  at
                         least  one  change  and not checkpoint for 10
                         minutes.


          Very Bad Time: Done when composing a message. In  this  case
                         Pine  will  only  checkpoint  if  at least 48
                         changes have been made or one change has been
                         made  in  the  last  20 minutes with no check
                         point.


          Disk Quotas and Usage


               All mail files are stored under  the  "mail"  subdirec-
          tory. A command in the "other" menu shows the disk usage and
          free space. The total that is shown for mail folder  is  the
          total of the files found in the mail subdirectory. The shown
          number for the free space is either the space  left  in  the
          users disk quota or the space left on the disk drive, which-
          ever is smaller. The text associated with the  message  will
          say which. If the user is over his quota, that will be shown
          and a message will be displayed  when  the  user  starts  up
          Pine. Pine knows how to access the standard UNIX quotas data
          bases, well at least two versions of it.







                                     - 34 -

                            - Pine Technical Notes -


          Alternate editor for composing


               In Pine 3.0 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  com-
          poser.  It  operates in one of two ways. If you select "old-
          growth" mode in your .pinerc you can type "^_" while in  the
          composer  and  be  prompted  for  the editor. If you set the
          "editor" variable in your .pinerc then "^_" will  appear  in
          the  composer key menu and will invoke the configured editor
          when you type it.


               We know that many folks would like to  use  the  custom
          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 prob-
          lems is that you lose access to  the  address  book.   There
          will probably be further discussion on this!...


          Pico


               The message composer in Pine is  actually  compiled  in
          and part of Pine. Pico is a stand-alone version of that edi-
          tor that can be used to edit text files  or  other.  It  has
          word wrap, justification and spelling just like the composer
          in Pine. It has the following command line options:


          -f   Turn on function keys

          -nN  Turn on new mail checking every N seconds

          -v   View file only, no editing

          -w   Disable word wrap

          -z   Turn on ^Z suspension

               The Pico man page has more details and lists more  com-
               mand line options.


          Mail folders and formats


               Just about all mail folders are kept in the "mail" sub-
          directory.  The  one exception is "inbox" which is more of a
          place holder for what ever is the standard place to get  new
          mail  on  the system. The default format used by Pine is the


                                     - 35 -

                            - Pine Technical Notes -


          Berkeley mail format. It is used by the standard "mail" com-
          mand  and  by  elm. Basically mail messages are separated by
          lines that look like:

          From deroest@daffy.cac.washington.edu  Fri Jan  11  14:32:33
          1991


               If a file doesn't look like this,  Pine  will  consider
          it's  format  to be invalid and refuse to open the file. The
          use of his format is also the reason you  will  occasionally
          see  ">From"  in  the  mail  message  text.  The ">" must be
          inserted so there is no confusion between the  text  of  the
          message  and  the  separator.  This  is a silly problem that
          should have been solved long ago with a more reasonable mail
          file  format. The sender and date information in the separa-
          tor are not used by Pine.  You can fool Pine into thinking a
          file  is  a mail folder by adding a message separator at the
          beginning of the file and where ever you want message  boun-
          daries.  Pine  believes the message header ends at the first
          blank line in message.


               Pine also knows how to read other file formats,  namely
          Tenex and USENET News.


               The inbox folder is treated specially. It  is  normally
          kept  open  constantly  so  the  arrival  of new mail can be
          detected. The name "inbox" refers to where ever new mail  is
          retrieved  on the system. If the inbox-path variable is set,
          "inbox" refers to that. The "sent-mail" and  "saved-message"
          folders  are also some what special.  They are automatically
          created if  they  are  absent  and  recreated  if  they  are
          deleted.


               Pine provides an "export" command to write the contents
          of  a message to a file for use outside of Pine. When a mes-
          sage is written this way Pine pays attention  to  the  umask
          for  the  setting of the file permissions. When a message is
          saved to a folder, the folder is created  so  that  read  or
          write permission is granted only to the owner of the file.


          Message Status and the expunge command


               Each message has some status flags. Pine  only  uses  a
          few  of  the  flags supported by the Berkeley format and the
          c-client. A flag is set if the message  is  new  and  hasn't
          been  read.  An  "N"  shows in the messages index. The other
          flag used is "D" to mark a message as deleted.  The  message


                                     - 36 -

                            - Pine Technical Notes -


          is  not actually deleted until the mail box is expunged. The
          expunge operation basically deletes all the messages  marked
          for  deletion.  The  user  may give the "X" command to do an
          expunge any time he wants to, or may wait till he is exiting
          Pine  or  closing  the  folder,  when  Pine offers to do the
          expunge.  Internally, the message  status  is  kept  in  the
          "Status:" and "X-Status:" fields in the message header.


          Sorting


               The mail index may now  be  sorted  by  subject,  size,
          sender,  date and arrival order. The "z" command will prompt
          the user for the sort order. The  sort  order  can  also  be
          specified  on  the  command line with the -sort flag. When a
          user changes folders, the sort order will  go  back  to  the
          original  sort order, usually the arrival order. The command
          line sort specification changes  the  original  sort  order.
          Each sort order can also be reversed.


               When a folder is sorted and new  mail  arrives  in  the
          folder  it  will  be inserted in it's properly sorted place.
          This can be a little odd when the folder is sorted by  some-
          thing like the subject.


               The sorts are all independent of case. and ignore lead-
          ing  or trailing white space. The subject sort ignores "Re:"
          at the beginning and will soon ignore "(fwd)"  at  the  end.
          The  sort  of sender sorts by the userid, not the full name.
          The arrival sort is basically 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. Usu-
          ally only the first sort is slow though 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.


          Feature level


               Pine now has a settable feature level for users of dif-
          ferent  experience.  This  is  only partially implemented in
          Pine 3.0. The planned levels are "seedling",  "sapling"  and
          "old-growth".  In  Pine  3.0  there  are  only "sapling" and


                                     - 37 -

                            - Pine Technical Notes -


          "old-growth" modes, and the only difference is that the  "h"
          command  to  show  full  headers  is available in old-growth
          mode. A command to pipe messages into other programs is next
          in the plan for old-growth.


          Anonymous Readonly Mode for News


               Pine has a mode appropriate for anonymous access  to  a
          folder  or  a  news group. This leaves off the sender of the
          message in the index and allows no  status  updates  to  the
          folder  or  news group. Messages cannot be deleted or saved.
          Mail cannot be composed, though mail can be forwarded.  This
          is usually used with the -i and -f options.




          Section III -- Compiling, Debugging, Porting and Source Code


          Debug files


               If Pine is compiled  with  the  DEBUG  option  on  (the
          default  in Pine 2.0), then pine will produce debugging out-
          put to a file. The file  is  normally  .pine-debugX  in  the
          users  home  directory where X goes from 1 to 4. Number 1 is
          always the most recent session and 4 the oldest. 4 are saved
          because  often  the  user  has gone in and out of Pine a few
          times after a problem has occurred before the  expert  actu-
          ally  gets  to look at it. The amount of output in the debug
          files varies with the debug level. The default is  level  2.
          This  shows  very general things and records errors. Level 9
          produces rather copious  amounts  of  output  for  each  key
          stroke.


          Memlog


               There's a few source files and hooks in the Pine source
          to  log  each memory allocation and each free. This was used
          to check and debug memory leaks. The  few  found  are  fixed
          now. The code is retained for future checking. Two makefiles
          exist for compiling with the memory logging  turned  on  for
          the  "nxt"  and "ult" platforms. This hasn't been used for a
          while so it might not quite work. A log of  the  allocations
          and  frees  is written to a file along with frequency counts
          and the net outstanding amount of leaked memory.  Pine  runs
          much less efficiently when this is enabled.



                                     - 38 -

                            - Pine Technical Notes -


          Signals, aborts and core dumps


               Pine catches SIGHUP and does the best thing with it. If
          a  message  is  under composition it will be saved as inter-
          rupted mail which can be continued by  going  into  compose.
          SIGHUP  occurs  when the session is disconnected for reasons
          such as a modem hanging up, the client workstation rebooting
          or  other.  Pine also catches SIGQUIT (^\) and asks the user
          if he really wants to quit. This was added because we  found
          many  pine core files generated by nothing other than ^\. ^\
          is retained so there is some emergency exit.


               If pine is not compiled  for  debugging  or  the  debug
          level  is  set low Pine will also catch the other abort sig-
          nals like SIGSEGV (segmentation fault) so it  can  clean  up
          the  tty  modes  and exit. It prints a message that a bug in
          Pine has been encountered and dumps  a  core  file.  If  the
          debug  level  8 or higher then these signals won't be caught
          and the core dump will just happen.


          Pine help text


               The file pine.hlp contains all the help text for  Pine.
          Normally,  it  is  compiled  right  into  the Pine binary as
          strings. This is done to simplify  installation  and  confi-
          guration.  The  pine.hlp file is in a special format that is
          documented at the beginning of the file.   Basically  it  is
          divided  into sections, each with a name that winds up being
          referenced as a global variable. There is also some  special
          formatting  to keep things lined up and to allow for substi-
          tutions in the help text depending on whether the key labels
          are  the  standard alphabetic/mnemonic or they are the func-
          tion keys. These files are processed by two awk scripts  and
          turned into C files that are in turn compiled in to Pine.


               This scheme can increase efficiency when Pine  is  com-
          piled  to have the strings as part of shared read-only text.
          This works on machines that have  separate  instruction  and
          data  space,  which  is most machines today Rather than each
          process having to read in the help text  from  a  file,  the
          strings are shared by all executing processes on the machine
          and demand paged.  At the moment the Dynix port and the NeXT
          port  do  this.   How  to go about this for other ports will
          depend on the compiler. On the NeXT it  is  automatic.  With
          Dynix it required some work. The file with the help text had
          to be compiled with the -R option. In  addition,  on  Dynix,
          xstr is used to reduce all the identical strings to a single
          occurrence. This was done  because  higher  performance  was


                                     - 39 -

                            - Pine Technical Notes -


          needed for the Dynix version because of very heavy use.


          Source code organization

           The source code is in four directories with a shell script,
          "build", that descends into each and invokes the appropriate
          makefile to compile Pine and related  programs.  The  direc-
          tories are:

            - c-client: This is a set of library routines that form an
          interface to the mail store and act as a switch between dif-
          ferent mail  file  formats/drivers.  Currently  it  supports
          IMAP,  Berkeley  format (elm, mail..), Tenex and netnews. It
          also does all the RFC-822 parsing (a very thorough job)  and
          is one of the pilot implementations of the upcoming Internet
          standard, "MIME" for multipart mail. Also, in  the  c-client
          directory  is  mtest,  a very simple stand alone mail client
          that uses the c-client. It's useful for testing the c-client
          or  imap  connections  independent  of  a more involved mail
          client.  The c-client included here is only a  minimal  part
          of  the imap source tree. If you plan on doing anything more
          with imap and the c-client than using or  porting  Pine  you
          should    get    the    full    imap    source   tree   from
          ftp.cac.washington.edu. Mark Crispin is the  author  of  the
          c-client and IMAP protocol.

            - pico: Pico stands for PIne's COmposer. The  source  here
          is for the Pico library and the Pico main program. When com-
          piled with Pine it is the Pine  message  composer,  spelling
          checker  and such. When compiled against the Pico main it is
          the stand alone Pico  editor.  Pico  is  in  part  based  on
          micro-emacs and is written by Mike Seibel

            - imapd: The imapd daemon.  This  is  a  small  amount  of
          source  to turn the c-client library into a daemon that runs
          on a mail server to serve imap clients. This is only  needed
          if you are using the imap protocol.

            - pine: The code here is the primary Pine user  interface.
          It  relies on the c-client and pico libraries and implements
          all the Pine screens except the composer. It also implements
          the  address  book, configuration files and includes the on-
          line help text.

            - contrib: This directory contains  contributed  additions
          to Pine


          Porting Pine to other Platforms





                                     - 40 -

                            - Pine Technical Notes -


               Substantial effort has gone into  making  Pine/Pico  as
          portable  as  possible. There are still, of course, a number
          of machine dependencies.  We've picked  a  small  number  of
          platforms  for which we will do our best to provide a tested
          and running port.  Currently they are Ultrix,  NeXT,  SunOS,
          Dynix and AIX/370. We are also willing to redistribute ports
          to other platforms as they conform to  the  invented  scheme
          for handling different platforms.


               Each platform is given a three  letter  name  (see  the
          file  doc/pine-ports).  Make up a new one for your new port.
          We've tried to bring  all  potential  platform  dependencies
          into  three files, os-xxx.h, os-xxx.c and makefile.xxx where
          xxx is the three letter name of the port. Thus any new  port
          will  hopefully  just  result in new versions of these files
          and some notes for the pine-ports  file.  This  is  actually
          nine  new  files  because there are a set of these files for
          the c-client, pico and pine source directories.


               The make files are kept as simple and straight  forward
          as  possible because many previous attempts at automatically
          figuring out what to do seem to become complex and  ineffec-
          tive  in what they set out to do: make compiling and instal-
          ling  the  program  easy.  Each  port  is  for  a   specific
          hardware/software  platforms,  also because past attempts to
          generalize on versions of  UNIX  or  some  CPU  architecture
          don't  seem  to  have gained much. Thus, there is a separate
          makefile for each platform that calls the  appropriate  com-
          piler, archiver and linker with the appropriate flags.  Most
          of these makefiles are pretty  similar.  The  makefile  also
          specifies  which  of the os-xxx.c and os-xxx.h files to use.
          It is the root from which   all  platform  dependencies  are
          selected.  In some cases the makefile defines a symbol named
          after the platform on which there can be dependencies in the
          source  code.   Pine,  Pico  and the C-client don't quite do
          everything the same  (there  are  three  authors  involved).
          Basically  to  build  the  source in a directory for a given
          platform, run "make -f makefile.xxx" where "xxx" is the  the
          three letter name of the platform.


                The file os-xxx.h is used for general platform  depen-
          dent  #include's  and #defines. A few things that affect all
          the source are here, such as a macro defining the type  that
          qsort() and signal() return. All the include files that have
          been found to vary from one platform  to  another  are  also
          included  here.  In the case of Pine and Pico, there is only
          one os-xxx.h file called os-unx.h for  the  officially  sup-
          ported  ports  and  inside  it  are  #ifdefs on the platform
          specific symbol defined in the makefile. For the current set
          of  ports, which have more in common than different, this is


                                     - 41 -

                            - Pine Technical Notes -


          simpler.  If the changes to os-xxx.h become large it will be
          better to create a new os-xxx.h file named for the new plat-
          form.  We also prefer new os-xxx.c and  os-xxx.c  files  for
          new  ports so that we don't have to merge any source.  There
          are a number of Pine configuration settings that are defined
          here  such as the place it looks for certain files, defaults
          for the printer and folder names, the  maximum  screen  size
          and so on.


               The os-xxx.c file contains functions  that  are  poten-
          tially  platform dependent. Again, the idea is to gather all
          the dependencies in one place. Pine and Pico  use  the  same
          strategy  here  as  used with os-unx.h.  Since Pine has been
          ported to both Berkeley and System V UNIX most of the  func-
          tions for any given port have been created thus doing a port
          is usually a matter of finding the appropriate functions  in
          from  the  existing  ports.  For example, there are two ways
          different systems do dates and time zones so you'll find two
          different  versions  of  rfc822_date() in c-client/os_aix.c,
          and c-client/os_ult.c.  The  other  c-client/os_xxx.c  files
          have one or the other version of these functions.


               It is strongly encouraged that no changes  be  made  to
          the general source when porting and that all changes be con-
          tained to the three/nine system dependent files. The  object
          is to maintain source code integrity and assimilate ports to
          new platforms rapidly. The more conventional way to do  this
          is with a large collection of #ifdefs. The problem with this
          is that adding a port for a new  platform  implies  changing
          the  source  code  for  all  the other platforms and thereby
          risks breaking them. This scheme in Pine has  been  designed
          to  avoid  that, at the cost of making it a little harder to
          port Pine.




















                                     - 42 -

                            - Pine Technical Notes -


          Test Checklist


               The following is a check list for testing a new port:

          ___  Sending mail, check that full name is correct
          ___  Replying to and forwarding a message
          ___  Postponing message under composition
          ___  Make sure local user names are expanded
          ___  Test spelling checker
          ___  Catching of SIGHUP while message is composition
          ___  Setting of user-domain and use-only-domain in .pinerc
          ___  New mail notification. Should happen with Pine idle  to
               check timeouts
          ___  Reading mail in index
          ___  Deleting and undeleting
          ___  Expunge to empty folder
          ___  Make sure that "~" expansion works
          ___  Save message to folder, check error conditions such  as
               permission denied
          ___  Export message
          ___  Checkpointing (make 20 status changes, or 19  and  wait
               30 sec)
          ___  Open IMAP and RIMAP folders
          ___  Test opening bogus folders: invalid format, no  permis-
               sion
          ___  Open a USENET news group via IMAP
          ___  Pine -f option
          ___  Disk quotas and usage (over, under, and device space)
          ___  Change password
          ___  Lock keyboard
          ___  Address book operations
          ___  Take command
          ___  Send mail with empty address book
          ___  Make sure that  SIGQUIT,  ^ confirmation  works  (check
               core dump too)
          ___  Test panic (Give '#' command on main  menu  with  debug
               level > 8)
          ___  Make sure SIGSTP, ^Z works (-z option)
          ___  Pinef
          ___  Sent-mail pruning
          ___  Printing using all three printer configurations
          ___  View help text & news
          ___  Folder list operations (rename, create, delete...)
          ___  Window resizing
          ___  Error messages for incorrect terminal types (try  "foo"
               and "vt52")
          ___  Reading of /usr/local/lib/pine.conf







                                     - 43 -

                            - Pine Technical Notes -


                Section IV -- Differences between version 2.4 and 3.0


               This may be a bit rough and tumble, but hopefully  will
          provide enough information for system administrators to know
          what they are getting into by installing Pine 3.0  (3.02  by
          now).


               The biggest change in Pine is  the  support  for  MIME.
          This has affected a lot of source code. All seems to be run-
          ning well, but some of the MIME functions themselves are not
          highly polished. See the section on MIME for more details on
          what it is all about. The one case we've seen where MIME can
          intrude into normal non-MIME operations is when users either
          accidentally or intentionally include 8  bit  characters  in
          outgoing  messages.  This  will  cause  Pine  to  apply  the
          quoted-printable encoding to turn it into 7 bit ASCII  since
          8 bit characters are not allowed in Internet mail (though it
          often works and  some  make  use  of  it).  Other  than  the
          "Attchmnt:" field showing in the compose and the "A" command
          in the Mail Viewer, most users will not notice  any  differ-
          ences because of the MIME support.


               The Pine main menu has a bit of a  new  look.  The  "V"
          command  has  been moved off the main menu as we found some-
          thing like half of the Pine users at the UW were  not  using
          the index at all. Instructors in the training classes always
          had to introduce folks to the index. Some users  would  even
          lose  mail because they couldn't figure out where their mail
          was.  By default, this version of Pine displays an  explana-
          tion  for the change in the main menu and a message that the
          previous version can be had with  "pine.old".  This  can  be
          turned     off     by     putting     "new-version=no"    in
          /usr/local/lib/pine.conf. The "News" item was moved into the
          "Other"  menu  and the "Who to Call" text is now included as
          the first page of the help text on the main menu.


               Pine and Pico now include a file browser for  selecting
          files  to  be  included "read in". The user can navigate his
          directory trees and such. This is invoked by typing ^T  when
          prompted for the file name.


               New features that shouldn't have any caveat's are:

          +    Index can be sorted by subject, sender,  size,  arrival
               or date
          +    Command line option to specify sort order
          +    Confirms  with  user  before  sending  message  to  the
               mailer-daemon


                                     - 44 -

                            - Pine Technical Notes -


          +    New command line option "-i" to go  directly  into  the
               index
          +    New command line option "-nr" for news/readonly mode
          +    Bcc saved in sent-mail and shown when viewed
          +    Fixed bug causing core dumps with very long addresses
          +    No limit on the number of messages in a folder
          +    Fix for address book screen painting problem with  Pro-
               comm and with composing on VT102s at low speeds
          +    Passes ISO-2022 character set  shift  escape  sequences
               for the display of Japanese and other languages
          +    Pays attention to  umask  when  exporting  messages  to
               files
          +    Option in .pinerc to have signature at bottom  of  mes-
               sage
          +    More efficient screen painting for low speed use
          +    Upon opening a folder the current message is now  first
               unread, ("N") message
          +    Pine.conf  and  .pinerc  variable  can  reference  UNIX
               environment variables
          +    Long line wrapping improved, now broken at spaces
          +    Checkpointing is less frequent and  at  more  opportune
               times
          +    Carries received date along properly for Berkeley  mail
               file format
          +    Disable ^Z suspension when keyboard is locked
          +    Shows READONLY or CLOSED with the folder name in  title
               bar
          +    When viewing mail,  the  header  is  displayed  in  the
               canonical "Full Name <address> format". Order of header
               is also uniform.
          +    Title bar format slightly different -- shows "Folder: "


               There is now, or will be different modes for  different
          user  levels.  Three modes are planed: "seedling", "sapling"
          and "old-growth".  Currently,  Pine  defaults  to  "sapling"
          mode. There is also "old-growth" mode that adds the "h" com-
          mand to view the full header and the  "^_"  command  in  the
          composer  to  select  an  alternate  editor. These modes are
          selected with the user-level variable in the .pinerc.


               There are a number of new  configuration  variable  for
          pine.conf and


              smtp-server
              editor
              image-viewer
              feature-level
              old-style-reply
              signature-file
              mail-directory


                                     - 45 -

                            - Pine Technical Notes -


              character-set
              show-all-characters
              new-version



               One can now use their favorite editor to  compose  mail
          in  Pine!  If  the editor variable is set in the .pinerc the
          "^_" command to start the editor will show in the  composer.
          Alternately,  when  operating  in  old-growth mode, the "^_"
          command can be given, even it it's not displayed.  You  will
          be prompted for the editor of your choice.


               There are now ports for Dynix/PTX and HP/UX. These  are
          both  System  V based and Pine is generally more portable to
          System V platforms.






































                                     - 46 -

                            - Pine Technical Notes -

                             Version 3.0, July 1992

          Section I -- Installation, Design and Internals .......    1
          Building and Installation .............................    1
          Design goals ..........................................    3
          IMAP (The Interactive Mail Access Protocol) ...........    4
          Address Formats (RFC-822 Compliance) ..................    5
          Known Bugs and Problems ...............................    6
          Domain names ..........................................    6
          Pine Configuration (system wide and per user) .........    8
          Mail folder  reading,  writing,  locking  and  check
               pointing .........................................   12
          Terminals and Termcap .................................   14
          Memory Usage ..........................................   14
          Sendmail, SMTP and mail delivery ......................   15
          The Berkeley Mail file format and locking .............   15
          Accessing mail folders via NFS ........................   16
          MIME -- Multipart Internet Mail Extensions ............   17
          International Character Sets ..........................   20
          Section II --  Functions/Reference ....................   21
          Command Line Arguments ................................   22
          Address Book ..........................................   23
          Sent Mail Pruning .....................................   24
          Signatures and Reply/Forward formats ..................   25
          Spelling checker ......................................   25
          Postponing mail .......................................   27
          Interrupted Mail ......................................   28
          Printers and printing .................................   28
          Function Keys and Keymaps .............................   29
          New Mail Notification .................................   32
          Mail folder checkpointing .............................   33
          Disk Quotas and Usage .................................   34
          Alternate editor for composing ........................   34
          Pico ..................................................   35
          Mail folders and formats ..............................   35
          Message Status and the expunge command ................   36
          Sorting ...............................................   37
          Feature level .........................................   37
          Anonymous Readonly Mode for News ......................   38
          Section III --  Compiling,  Debugging,  Porting  and
               Source Code ......................................   38
          Debug files ...........................................   38
          Memlog ................................................   38
          Signals, aborts and core dumps ........................   39
          Pine help text ........................................   39
          Source code organization ..............................   40
          Porting Pine to other Platforms .......................   40
          Test Checklist ........................................   43
          Section IV -- Differences between  version  2.4  and
               3.0 ..............................................   44











                            - Pine Technical Notes -


          (Note: This is not intended to be a complete document,  only
          helpful notes)





















































                                     - 48 -
Newsgroups: comp.sys.att