I've been unavailable to maintain this port for quite a while and thanks to
some very capable people this port hasn't died of horrible bitrot.  My hat's
off to everyone who stepped in and kept this monstrosity up to date.

I'm providing a mega-patch which updates the port to 0.44.2 and fixes the
issue of LDAP support not getting built.  Thus the following PRs can be
closed:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/60727
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/60748
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/61082

There's quite a few cosmetic changes to the port as well.

I had filed <http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/33929> almost
two years ago to register the UID/GID for 'courier'.
<http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/33929> is still marked
open and has led to the conflict with security/pf reported in
<http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/58115>.  I had considered
using mailnull when I was writing this port but rejected that idea beacuse
that's the sendmail queue user.  Installing a port with lots of suid
binaries set to a user of an entirely different MTA is a Bad Thing IMHO.
Presumably mailnull was thought up with the idea that no binaries would ever
be owned by that user.  Besides mail/courier/pkg-deinstall depends on the
home directory of the user courier is installed as to be courier's queue
directory not sendmail's.  mail/courier/pkg-deinstall asks the user if the
/var/spool/courier/ can be removed upon deinstall.  And changing mailnull's
home directory to accommodate courier would be a Bad Thing too.  There's
another unadvertised "feature" in having user <courier> with it's own home
dir. /var/spool/courier/.noident is installed and provides a bit of security
by obscurity by not advertising to the world which user courier is running
as whe then inetd(8) has the auth service turned on.  So how about we
register in the Porter's Handbook UID/GID 465 as courier (taken from
/etc/services smtp over TLS/SSL port number).

files/patch-configure and files/patch-courier::configure are new with this
patch and files/patch-courier::configure.in is removed.

CONFLICTS has been expanded.
WITH_GHOSTSCRIPT_AFPL support has been changed to honor GSPORT

The WITH_LDAP issue happened because I was setting:

CONFIGURE_ENV+=	LDFLAGS="${LDFLAGS}"

which was getting clobbered by <bsd.openssl.mk> doing the same thing so that
in the end CONFIGURE_ENV would expand to:

LDFLAGS="-L${LOCALBASE}/lib" LDFLAGS="-rpath=/usr/lib:${LOCALBASE}/lib"

instead of the intended:

LDFLAGS="-L${LOCALBASE}/lib -rpath=/usr/lib:${LOCALBASE}/lib"

The subtlety which led to this bug was that I never actually declared
LDFLAGS in a Makefile -- only in scripts/configure.courier
Perhaps the behaviour in <bsd.openssl.mk> regarding the interaction between
LDFLAGS and CONFIGURE_ENV should be documented if it isn't already.

While I was at it I got rid of OpenLDAP 1.x support keeping only the
OpenLDAP 2.x and now honor the WANT_OPENLDAP_VER tunable.

WITH_TRANSPORT+=uucp changed since uucp is no longer part of the base system
and NOUUCP is no longer a /etc/make.conf tunable for buildworld.

WITH_EXPECT not being set now adds --disable-changepass which causes the suid
authdaemon.passwd to not be installed.

LIB_DEPENDS= fam.0:${PORTSDIR}/devel/fam
is non-optional since the port will use the library if it finds it
regardless of one's intention to use it or not.  For instance if libfam is
installed and one doe not want it used by courier but chosses the WITH_LDAP
support than libfam will get sucked in as well.  Then the user deletes fam
and courier breaks because the user had no idea courier depended on it.  So
until courier gets a configure --without-fam tunable this should be a
mandatory dependency.

and last but not least etc/rc.d/courier.sh startup script has been rewritten
to work with rc.subr which allows one to move it to /etc/rc.d/courier and
have it just work. :)

How-To-Repeat: cd /usr/ports/mail/courier
make WITH_LDAP=yes install