maildrop is compiled without authlib extension !

Hallo

Me too, i go back to 0.58 and set it on hold

lg chris

This just caused me to lose email after an upgrade... hopefully it's just a small oversight that can be rectified easily to save other people this misfortune.

I suspect the problem to be lines 116-119 of maildrop/configure.in:

if test -d ${srcdir}/../courier
then
    COURIERAUTHCONFIG=""
fi

This check was added since the version of courier in hardy and appears to disable authlib support if maildrop is being built as part of the courier package (as it is here, before being split out into separate packages). I'm not sure why it does this!

To solve this problem use the original debian packages at http://packages.debian.org/lenny/courier-maildrop.
But be careful. Ubuntu wants to get rid of it by installing their own version via apt-get/aptitude.

The problem still exists in ubuntu 9.04 and 9.10.

I am using DTC which installs this package by default and had the same problem. I had to use TDS' solution which works fine except that apt-get keeps complaining that it wants to install a new version from the ubuntu repositories.

With aptitude, you can hold a package using
     aptitude hold package_name

and remove the hold with
     aptitude unhold package_name

Our solution would be:
aptitude hold courier-maildrop

thanks TDS.

Still would like to see this fixed for Lucid+1. :-)

I also fixed this by using the version from Debian Lenny (0.60.0-2). I then pinned the version by putting the following in /etc/apt/preferences:

Package: courier-maildrop
Pin: version 0.60.0-2
Pin-Priority: 500

This is a pretty serious regression, SRU worthy I would think as every version since 8.04 has been totally unusable for a number of users and can lead to loss of user data (incoming emails which will be rejected).

I ran into this problem while upgrading 8.04 to 10.04 for a system running Domain Technologie Control (DTC) web admin panel. I fixed it by getting the source package for courier-maildrop, editing the configure.in in the maildrop directory as follows:

dnl if test "$COURIERAUTHCONFIG" != ""
dnl then
        AUTHINCLUDE=`$COURIERAUTHCONFIG --cppflags`
        dnl AUTHLDADD="`$COURIERAUTHCONFIG --ldflags` -lcourierauth"
        dnl RPD: also had to add -L for the authlib library dir
        AUTHLDADD="`$COURIERAUTHCONFIG --ldflags` -L/usr/lib/courier-authlib/ -lcourierauth"
        AUTHLIB=1
dnl fi

which forces compilation with authlib, then doing a dpkg-buildpackage -sn -uc, installing the new .deb, and then locking the version so that it wouldn't get stomped in a future upgrade. The crucial step in diagnosing the problem was seeing that authtest from the command line would verify the user, but maildrop -v showed that base version of maildrop with 10.04 was not compiled with support for courier authlib. After recompilation, maildrop -v showed maildrop had authlib support in it.

Does anyone know if this has been fixed in 10.10 or 11.04?

agent, its still open as "Confirmed" meaning its reproducible but we haven't looked to see if it exists in Debian and/or has been fixed upstream.

Ok I just confirmed it is fixed in Natty and Lucid. Lets just assume its ok in Maverick as well. Karmic is almost EOL so not checking that. At this point, I think this one is closed.

Thanks for taking a look at this but I just verified that Lucid is still broken.

courier-maildrop 0.63.0-2.1ubuntu1

maildrop -v
maildrop 2.1.0 Copyright 1998-2005 Double Precision, Inc.
GDBM/DB extensions enabled.
Maildir quota extension enabled.
This program is distributed under the terms of the GNU General Public
License. See COPYING for additional information.

It does appear that Maverick has been fixed.

courier-maildrop 0.65.0-1ubuntu1

maildrop -v
maildrop 2.5.0 Copyright 1998-2005 Double Precision, Inc.
GDBM/DB extensions enabled.
Courier Authentication Library extension enabled.
Maildir quota extension are now always enabled.
This program is distributed under the terms of the GNU General Public
License. See COPYING for additional information.

I still believe this is a major regression. It should be fixed in Lucid.

OOOPS agent, I must have confused myself when confirming on lucid. Thanks, I've opened the bug task for lucid and marked it High.

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".