Welcome to nail, a mail user agent!

Nail is derived from Berkeley Mail 8.1 and is intended provide the
functionality of the POSIX.2 mailx command with additional support
for MIME messages, POP3 and SMTP.

To compile nail, look at the file 'INSTALL' that documents the
configure options. You can also build nail RPMs using 'rpm -ta
nail-<version>.tar.gz'.

After compilation, edit the personal and system-wide run time
configuration files to match your needs. You _really_ should do this or
at least install the template because most of the defaults still have
the compatibility values of fifteen years ago.  For batch usage, it may
be more convenient to pass the configuration as environment variables
only, as e. g. 'MAILRC=/dev/null from=user@host nail -n' does.

Nail has been built successfully on the following systems:

Linux 		2.x; glibc 2.x, libc[45]
Solaris		9; 8; 7; 2.6; 2.5
Open UNIX	8.0.0
UnixWare	7.[01].1; 2.1.2; 2.1
OpenServer	5.0.5
Digital Unix	4.0
HP-UX		10.20
SINIX-Z		5.42
AIX		4.3.3.0
FreeBSD		4.0-STABLE, 4.5-RELEASE, 4.6-RELEASE
OpenBSD		2.[89], 3.0, 3.1-current
NetBSD		1.5
Mac OS		10.1 (but note that there is no support for
		case-insensitive file systems and other possible
		Mac OS oddities).

If you can build it on other operating systems, please contact me
and send me a diff with your changes so I can include them in this
archive (preferably a unified diff, gnu-diff -u). If there are no
changes, even better, but I would like to hear from you even then
to extend this list.

It should generally be possible to build nail on most Unix-style
systems without much effort; however, especially the character set
support varies between them. See the file 'I18N' for details.

On the other hand, I strongly discourage from porting nail to Windows
and environments that make Windows look Unix-like; I won't accept any
patches or suggestions that go in this direction. There are two major
reasons for this: First, any port makes maintaining harder; there are
always more work-arounds in the source, and introducing new features
involves the question whether they will work an all supported platforms.
The more different a platform behaves from, let's say, the common Unix
way, the more hacks have to be made, costing human time that could
otherwise have been used to enhance the software for Unix platforms.
Windows is just not worth this, and here we are at the second point:
Porting software to Windows encourages people to use -- that is: to buy
-- Windows. It supports a company that is known to threaten Open Source
software like nail. In short, porting nail (or similar free software)
to Windows has an ill effect on that software. Don't do it.

Note that my statement doesn't legally restrict you if you want to port
nail to any platform. This would not be the way of free software either,
especially since I might be wrong in the future; as an example, porting
free software to mainframes of a certain company is considered a good
thing today. I just wish to express my opinion as a free software
developer, and to inform you that I don't maintain such a port.

The mbox format variant based on the 'Content-Length:' header field that
is used on most SVr4 systems by default is not supported by nail. As this
format generally is a design flaw, you should fix your system by either
using procmail for local mail delivery, which is a good idea anyway, or
at least add the -E flag to the Mlocal line in /etc/sendmail.cf if using
/usr/lib/mail.local.

Although it is not bad, just obsolete, similar considerations apply
to the MMDF format used on OpenServer systems; unless you switch to
procmail (or contribute support for this format), nail will not be
able to read your mailbox there.

New nail versions will be announced on <http://freshmeat.net>. Nail's
home page is currently at <http://nail.berlios.de>. Please always look
for the newest version before reporting bugs.

If you detect a bug and cannot fix it yourself, please send me the
unaltered mail message (if any) that caused the problem along with a
description. This may be a privacy issue, but it is nearly impossible
to fix such errors without an exact reconstruction. If the problem
concerns the configure script, please include the relevant lines
of the generated 'config.log' file.

If you have an idea how to improve nail, especially one not already
mentioned in the 'TODO' file, you are also invited to write me. But
please understand that 1) maintaining a program sometimes involves
rejection of suggestions that fail to be consistently designed or
to be useful for more than just one person, and 2) I often don't
have the time to implement something even if I agree that it would
be a considerable improvement. If you decide to write the code
yourself and intend to contribute it, please contact me early so
that we can avoid the problems mentioned as 1).

Enjoy!

Gunnar Ritter
Freiburg i. Br.
Germany
<Gunnar.Ritter@pluto.uni-freiburg.de>				3/19/04
