University of Washington

Search Directories Reference Tools

Pine Information Center The Pine FAQ

Search Pine Information Center

Info for systems administrators, developers, etc.

7.1 Can we use Pine/Pico/Pilot source code in commercial products?

7.2 What are the advantages of the various mailbox formats Pine supports?

Pine, being based on the c-client library for messaging applications, supports several formats for mailboxes. For a comparative table and details on how to select the format Pine will use, and on mailbox name conventions, see, respectively, the files docs/drivers.txt and docs/naming.txt that are included in the UW IMAP server source distribution, which is available from:
ftp://ftp.cac.washington.edu/imap/imap.tar.Z

Basically, mbx is the recommended (and default) format for PC-Pine. (PC Pine 4.x supports mbx, mtx, tenex, and unix formats, all read-write. PC Pine 3.x supported mtx and tenex read-write and unix read-only.) For UNIX Pine, the mbx format, because it allows multi-session access, is recommended over the unix format if (and only if) NFS is not involved.

Using the mbx format allows multiple sessions (or multiple users, subject to the usual access controls) to have full Read-Write (RW) access to the INBOX. Message state changes (e.g. marking a message as deleted) and expunges can be done, and all such actions are automatically communicated to other sessions which have the mailbox open. In contrast: the normal Berkeley style folders can have only one RW client at a time, so given the current software the latest session steals the RW lock away from any previous session, with the earlier session becoming Read-Only. mbx format is also considerably faster and uses memory much more efficiently than the normal Berkeley style folder format.

An mbx format mailbox can be created by prefixing the desired name with "#driver.mbx/". For example, if you want an mbx format mailbox called "test", create "#driver.mbx/test". The "#driver.mbx/" prefix is used only when creating the mailbox; to open it, just use "test". A user can have their INBOX in mbx format as well, by creating "#driver.mbx/INBOX". Mail will be automatically moved from the mail spool to the mbx format INBOX whenever Pine or an IMAP/POP server is run.

CAUTION: mbx format uses read/write open modes and file locking, and depends upon local disk file semantics which are not present on NFS. Although mbx format will "work" via NFS, there are likely to be problems; consequently we do NOT advise using mbx format over NFS.

CAUTION: mbx format is supported only on software based upon the UW c-client library, such as Pine, imapd, and ipop3d. If you use other software, e.g. elm, mm, etc., you should not use mbx format.

7.3 Can Kerberos authentication be used with Pine?

More information about Kerberos can be found at:
http://web.mit.edu/kerberos/www/

7.4 How does folder locking work?

Because there are many different schemes of mail file locking used on UNIX, Pine implements all of them. The result is a lot of complexity. There are several reasons why locking needs to be done:

1. If you want to read the mail file, you want to make sure that no other process will modify the mail file while you are reading it.
2. If you want to write to the mail file, you want to make sure that no other process is accessing the mail file while you are writing it.
3. If you have the mail file open, you want to make sure that no other process can alter any of the internal contents of the mail file that you have read, but it is OK if another process appends new data to the mail file.
4. If you want to alter any of the internal contents of the mail file, you want to make sure that no other process has the mail file open.

• The creation of a file which has the same name as the mail file, but with a suffix of ".lock" (for example, this lock for /usr/spool/mail/isma is named /usr/spool/mail/isma.lock). This file accomplishes locks (1) and (2) above. This is an exclusive lock.
• The use of an flock() with LOCK_SH on the mail file. This accomplishes lock (1), and prevents lock (2). Multiple processes can do this.
• The use of an flock() with LOCK_EX on the mail file. This accomplishes lock (2), and prevents lock (1). This is an exclusive lock.
• The use of an flock() with LOCK_EX on a file on /tmp. The file name used depends upon the version of Pine. This accomplishes locks (3) and (4). This is an exclusive lock.

NOTE: flock() on BSD systems does not work over NFS, so only the most basic .lock file locking -- locks (1) and (2) happen over NFS. On SVR4 systems, fcntl() locking attempts to work over NFS, but there are known problems in the rpc.lockd daemon which have caused hangs if an application beats on the mechanism too much (and Pine beats on it). All of the above mechanisms work reliably over IMAP connections.

7.5 Where does Pine create lockfiles, and what should that directory's permissions be?

By contrast, lockfiles created in the /tmp directory serve interlocking of different Pine sessions with each other, not of Pine with the Mail Delivery Agent. Lockfiles in the /tmp directory are mode 666 because of the case of shared folders (e.g., tenex format) and "kiss of death" functionality (UNIX mbox format and MMDF format). The lock needs to be accessible by processes which may be logged in as another user name; this is a tradeoff between security and functionality.

[1] Versions of Pine prior to 3.92 did not warn users when locking in /var/spool/mail failed.

[2] Some version of the Linux operating system are being distributed with permissions that would require Pine to run setgid.

7.6 Why does Pine have problems with my filter's locking?

There are multiple levels of locking, just as there are multiple levels of operations on a mail file.

Pine reads the mail file and keeps a notion in memory of what messages exist and where they are in the file. It is alright to modify the mail file by appending new messages to it (which is what the mailer does in delivering mail) and Pine permits this to happen (it does not keep the file.lock style of lock locked).

However, if you modify the part of the mail file which Pine has already read, then Pine has no way of knowing what it is you might have done other than by tossing out everything it knows about the mail file and completely rereading it. In the internal engine used by Pine, this is done by a ``mail_close()'' followed by a ``mail_open()'' operation. Pine normally does not issue a mail_close() call on INBOX except when you quit Pine.

Pine detects that the file has been modified from under it and changes its notion of the internal state from ``representation of the mail file'' to ``snapshot of a representation of the mail file sometime in the past''. The difference between the two is that only the former will be written back to the disk if you do something such as a flag change or an expunge.

Pine also has an extra level of locking, to prevent the inadvertant modification of mailboxes from under it. This locking is implemented by the internal engine used by Pine. If you implement this sort of locking in your application, you can write code to steal this lock from Pine, or to prevent you from modifying the internals of the file (note that appending is OK) while Pine has it open. Source code for this locking is found in the file pine/imap/c-client/bezerk.c

7.7 Why doesn't Pine recognize Content-Length header field?

There are many serious technical problems with the Content-Length: header, and we do not recommend its use. Furthermore, we recommend that a mail delivery agent such as our tmail tool be used that applies smart quoting, as opposed to the ordinary BSD /bin/mail quoting of all lines that begin with "From ". We have installed such tools on all of our systems.

For example, one problem is that a system whose mailer does not implement Content-Length: will also not enforce its validity should that header appear. This offers significant potential for mischief. Another problem is that Berkeley format mailbox files which use the Content-Length: header can not be edited with an editor such as emacs or vi without invalidating the Content-Length: field. If this problem is not a consideration at your site, we recommend the use of the tenex format (mail.txt), which is also length tagged but in a much more efficient fashion.

7.8 How do I configure Pine to not leave mail in /usr/spool/mail?

1. Leave inbox in /usr/spool/mail, but turn on the Pine option to prompt users to move read messages to a folder in their home directory upon exiting Pine.
2. Modify your mail delivery program to deliver mail directly into the user's home directory, and specify that inbox-path in your global pine.conf (See the "tmail" program on ftp.cac.washington.edu for an example.)
3. "touch mail.txt" in each home directory, which will cause Pine (upon startup) to pull mail from /usr/spool/mail into ~/mail.txt -- however, mail.txt will be a Tenex-format, rather than Berkeley mail format folder (faster, but non-standard).
4. Link in the "mbox" driver when you build Pine. This driver will (upon Pine startup) pull mail from /usr/spool/mail into ~/mbox, which will be a Bky-format folder.

7.9 Why do I get the message "Unparsable Date" when I read messages?

The routine mail_parse_date() in pine/imap/c-client/mail.c knows how to parse some, but not all, of these symbolic timezones. We recommend that you modify this routine to add support for your own local timezone. Due to the ambiguity problem, however, it is unlikely that we will add any more symbolic timezones in the distribution sources. But, hopefully, this will only be a minor editing consideration for you.

The correct solution is to undertake the transition from symbolic timezone names to numeric timezone values. UNIX software is definitely moving in this direction due to the ambiguity problem, and has been doing so for several years now.

7.10 Why can't I compile Pine under SCO unix?

Pine has been tested and compiles just fine on a suitably equipped SCO Unix 3.2.4, and probably works on the whole 3.2 series (testing has not been as extensive). It handles both MMDF and sendmail mailboxes without needing recompilation. It should be sufficient just to unpack the source tree and run "sh build sco" at the top level. You need to own the complete Development System, and the Developer's Versions of the other packages. Pine will not compile without TCP/IP support.

The most common problem is when people own the Development System, but keep getting missing header files (netbd.h is one) in their builds. This is a common problem on SCO systems because of the great fragmentation SCO enjoys in the marketing of system components. It is easy to get confused about just what you've bought. And in this case, haven't bought. What you need is the "Developer's Version" of the TCP/IP product. The normal version just supports the TCP/IP protocol, but doesn't include tools (including header files) to compile TCP/IP-specific programs. Alas, the only remedies available to you are to pick up a pre-compiled version (mine is on odi.cwc.whecn.edu, ftp.celestial.com has their own, which prefers Bezerk mailboxes, though it supports MMDF too), or to buy the Developer's Version of TCP/IP. If you intend to do any serious compiling of Internet- available programs, I'd recommend the latter, though many of the most useful ones are available precompiled on other FTP sites.

7.11 How can I set up Pine for rimap under Solaris 2.4 and NIS+?

I have figured out how to configure Solaris 2.4 running NIS+ and Pine so that users may access an imapd server without having to provide their password yet not compromising the security of the imap server machine.

I hope that these instructions are useful to someone. Perhaps this will go in the FAQ.

You may also contact me if you have problems compiling Pine under Solaris.

0) Install /etc/rimapd

1) Reconfigure the Solaris nsswitch.conf
   The OS must know how to treat login requests.  We use NIS passwd entry
   rewriting to ensure the login security of the server machine.  Thus we
   must tell the OS to use NIS-style lookups.

   Edit /etc/nsswitch.conf on the computer running the imapd server.
   Replace the "passwd: [files] [nis] [nisplus]" line with:

passwd: compat
passwd_compat: nisplus

2) Tell the imap server machine about the machines that will be requesting
   remote logins

   Edit /etc/hosts.equiv and add the names of the trusted hosts:

host1.your.domain
...
hostn.your.domain

3) Configure /etc/passwd and /etc/shadow to filter NIS+ password entries
   This is where the security measures are made.  We "rewrite" password
   entries for users not in /etc/passwd, giving them a different shell -
   /etc/rimapd - which allows rlogin, but not shell access.

   Append this line to /etc/passwd:
+:x:-1:-1:::/etc/rimapd

   Append this line to /etc/shadow:
+::-1::::::

7.12 What do I need to do when compiling PINE to let users change their ``From:'' line?

Q&A submitted by: Timothy J. Luoma <luomat+pine@luomat.peak.org>

You must edit the appropriate file in the source code.  Assuming the current 
version of pine is 'x.y' you would need to go to pine.x.y/pine/osdep/ 
and edit the appropriate ``os-XXX.h'' file, where ``XXX stands for the
3-letter abbreviation for your OS.  Look for the line:

/* #define ALLOW_CHANGING_FROM  /* comment out to not allow changing From */

and change it to

#define ALLOW_CHANGING_FROM  /* comment out to not allow changing From */

and then compile as usual.

7.13 Is Pine ready for the year 2000?

As you may have heard, computer systems and software programs that store the year in date information as only two digits may encounter operational problems with the arrival of the year 2000.

Internally, Pine has never stored years as two digit values. The "last-time-pruned" variable might appear to be problematic, as this century's dates are represented as two characters, but this value is relative to the year 1900, so the year 2000 will be represented as "100" and so on. However, Pine version 3.96 and earlier do have a bug in their date-sort routines for the message index such that messages with a date in the middle of the next century will incorrectly sort before current messages. This bug is corrected in the Pine 4.00 code base.

The Message-ID that Pine generates does indeed use two digit years. However, this field is merely an identifier of a message, and is not otherwise defined. No internal Pine processes rely on anything specific (such as a date) within the Message-ID, and externally, anything that's sorting or otherwise relying on specific data within the Message-ID will run will run into serious problems (local version numbers, arbitrary SYSTYPE, etc.) long before the year 2000. Message-ID's will merely contain 00 instead of, say, Or, as one of our programmers put it when asked: "Ugh, and lengthen the thing some have complained is grossly excessive already!?! Seriously, changing the thing stands to actually break things that are parsing this undefined field already."

7.14 Where is the .pine-debug setting set at compile-time?

The default settings are defined in the os-XXX.h file inside the osdep directory in the pine source code directory, where XXX stands for the three-letter abbreviation for your Operating System; for example, the file pine/osdep/os-bsd.h would be used for those compiling PINE for BSD.

There are three settings:

DEBUGFILE = Where to put the output of pine in debug mode. Files are created in the user's home directory and have a number appended to them when there is more than one.

NUMDEBUGFILES = The number of debug files to maintain

DEFAULT_DEBUG = The default level of debugging information.

7.15 What do I need to do to configure specific servers for use with Pine?

• Microsoft Exchange 5.5: "Enable Fast Message Retrieval" (which causes Exchange to give an estimate of message size, rather than exact size) must not be selected; otherwise, messages when read by Pine may appear truncated or with "garbage" characters at the end. Unfortunately, even after turning "Enable Fast Message Retrieval" off, there is still a known bug in Exchange 5.5 in calculating the message size for certain types of MIME messages. Microsoft has told us (8 September 1998) that this bug is fixed in the next release of Exchange.

  Be sure also to set rsh-open-timeout to zero in pinerc, since rsh is not supported on NT/Exchange. If you do not, you will experience long delays in accessing the remote server.

7.16 What do I need to know about Pine file locking and what does the "mailbox vulnerable" error mean?

• Why did locking change in Pine 4.00?
  The actual locking mechanisms did not change in 4.00. What changed is that when one particular locking mechanism used by Pine fails, Pine now issues a warning message. Prior to 4.00, the locking failure would occur, but no warning was issued.
• Is this what the "Mailbox vulnerable" message is about?
  Yes. It means that Pine was unable to create a lockfile in the spool directory, generally because of overly restrictive protections on the spool directory. The correct permissions on the spool directory for running Pine are 1777, i.e. read-write-execute permission for everyone, with the sticky-bit set, so only owners of a file can delete them.
• Why does Pine require that the mail spool directory have 1777 protections?
  Pine was designed to run without special privileges. This means that in order to create a lockfile in the spool directory, it is necessary to have the spool directory permissions be world-writable.
• Can't you create the lockfile somewhere else?
  No. The lockfile in question must be in the mail spool directory, because that's where the mail delivery program expects to find it, and the purpose of the file is to coordinate access between the mail client (Pine) and the mail delivery program.
• Isn't having the spool directory world-writable a big security risk?
  No. Remember that the individual mail files in the spool directory are NOT world-writable, only the containing directory. Setting the "sticky bit" -- indicated by the "1" before the "777" mode -- means that only the owner of the file (or root) can delete files in the directory. So the only bad behavior that is invited by the 1777 mode is that anyone could create a random file in the spool directory. If the spool directory is under quota control along with home directories, there is little incentive for anyone to do this, and even without quotas a periodic scan for non-mail files usually takes care of the problem.
• Why not run Pine as setgid mail?
  Pine was never designed to run with privileges, and to do so introduces a significant security vulnerability. For example, if a user suspends Pine, the resulting shell will have group privileges. This is one example of why we strongly recommend against running Pine as a privileged program. In addition, a "privileged mailer" paradigm would mean that normal users could not test Pine versions or other mailers that had not been installed by the system administrators.
• Are there any alternatives to creating .lock files in the spool dir?
  There are, but they all have different sets of tradeoffs, and not all will work on all systems. Some examples:
  • Use lock system calls. Works fine on a few systems, provided mail spool is local. Doesn't work reliably if NFS is used. Doesn't work unless all the mail programs accessing the spool dir use the same calls.
  • Deliver mail to user's home directory. An excellent solution, highly recommended -- but one which is incompatible with some "legacy" mail tools that always look in the spool directory for the mail.
• Are these spool directory lock files the only kinds of locks used by Pine?
  No. Pine also creates lockfiles in the /tmp directory. For normal Unix mailbox format folders, these are used to coordinate access between multiple Pine sessions.
• What about the "quell-lock-failure-warnings" feature added in Pine 4.01?
  This is for people who are content to live dangerously, or who have specific knowledge that the spool directory lockfiles are superfluous on their system (because both Pine and the mail delivery program are using system call file locking in a context that works reliably, e.g. not NFS.)
• Where can I find more details on how Pine locking works?
  See the Pine Technical Notes.

Pine Information Center The Pine FAQ

Search Pine Information Center

Pine® Information Center Comments? Modified: October 28, 1999