|University of Washington||
|Pine Information Center The Pine FAQ||Search Pine Information Center|
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
For more Pine-specific information on email folder formats, see Folder Formats and Name Extensions in the Pine Technical Notes.
More information about Kerberos can be found at:
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:
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.
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
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 sendit or 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.
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.
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.
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::::::And you are done!
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 4.10 How do I change my 'From:' line? in Customization and Configuration. The Pine source code is available from ftp://ftp.cac.washington.edu/pine/.
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 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.
|Pine Information Center The Pine FAQ||Search Pine Information Center|
Pine® Information Center
Modified: September 23, 1998