|Search Pine Information Center|
Primarily, but may also be of interest to advanced end users. For more on Pine's "nuts and bolts" see the Technical Notes.
For information on use of Pine, Pico and Pilot software, see the Pine Legal
(formerly "What is a Tenex mailbox and why should I use it?")
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:
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.
Kerberos 5 support was added in Pine version 4.00; see the Pine Technical Notes for including Kerberos 5 functionality.
More information about Kerberos can be found at:
Locks are used by Pine and other mail programs to prevent damage from occurring to the mail file when multiple programs try to write to the file at the same time.
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:
There are several mechanisms of locking:
On SVR4-based systems, the lockf() subroutine or fcntl() system call it used instead of flock(). It is rumored that this creates a kind of lock file as well, but this has not been directly verified.
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.
To protect against conflicts with mail delivery by sendmail, which could cause INBOX corruption, Pine creates lockfiles in the directory /var/spool/mail . The permission setting for that directory should be 1777 (world writable with the sticky bit set). The alternative would be to make all mail programs setgid to some special group -- an unacceptable security risk in the opinion of the Pine developers .
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.
 Versions of Pine prior to 3.92 did not warn users when locking in /var/spool/mail failed.
 Some version of the Linux operating system are being distributed with permissions that would require Pine to run setgid.
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
It would be a significant detriment to the performance of the Berkeley format mailbox parsing code, as well as to Pine's behavior on normal systems which do not use the Content-Length: header, if any attempt were made to implement Content-Length:.
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.
You have several options:
This is probably caused by the mbox driver. If the file "mbox" exists on the user's home directory and is in UNIX mailbox format, then when INBOX is opened this file will be selected as INBOX instead of the mail spool file. Messages will be automatically transferred from the mail spool file into the mbox file.
If you delete mbox file, this behavior will no longer occur.
Pine parses the date and time in the UNIX mbox "From:" line in order to determine an "internal date" for each message. One of the components of this date and time is the offset from Universal Time. Certain older mailers write a symbolic timezone name instead of the more modern numeric offset, which expresses number of hours of deviation from Greenwich Mean Time (GMT). The problem with symbolic timezone names is that such names are ambiguous. Is BST "Bering Standard Time" or "British Summer Time"? Is KST in Korea or Kuwait? etc.
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.
Q&A from: Gunther Anderson <email@example.com>
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.
Q&A submitted by: David Drum <firstname.lastname@example.org>
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::::::
Beginning in Pine 4.30, allow-changing-from is the default.
In Pine 4.00 through 4.21, users can add allow-changing-from to the feature-list in their system configuration file (by editing the pinerc file, not via SETUP CONFIGURATION), and then add From to their customized-hdrs option. For previous versions, read on:
Q&A submitted by: Timothy J. Luoma <email@example.com>
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.
See also 9.5 How do I change my 'From:' line? in Customization and Configuration.
Q&A submitted by: Timothy J. Luoma <firstname.lastname@example.org>
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
Some messaging servers may require configuration changes to work properly with the Pine client (and perhaps other clients as well). This information is provided here only for the convenience of administrators of those servers, and not necessarily exhaustive or based on experiences or tests by the University of Washington.
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.
You should also consult the server's documentation on these issues.
There is an extensive section on locking in the Pine Technical Notes: Folder Locking; this information is intended to provide answers to some common questions:
If you want to convert mh to mbx folders, you should get a copy of the mbxcvt program, part of the imap-utils, located at the URL:
Then use something similar to the command "mbxcvt #mh/oldname mbx newname"
Read about Folder Collections in the Pine help to learn how to set up ~/Mail as a directory containing mailboxes.
If you want to access your existing mh folders without converting them, you can access them from Pine by prefixing the mh folder name with "#mh/" for example, to access your "foo" mh folder, use "#mh/foo".
For a comparative table and details on Pine formats, and on mailbox name conventions, see, respectively, the files imap/docs/drivers.txt, imap/docs/formats.txt and imap/docs/naming.txt that are included in the UW IMAP server source distribution, which is available at the URL:
|Search Pine Information Center|