Red Hat Bugzilla – Bug 188477
Review Request: maildrop
Last modified: 2007-11-30 17:11:30 EST
Spec Name or Url: http://nbecker.dyndns.org:8080/maildrop.spec
SRPM Name or Url: http://nbecker.dyndns.org:8080/maildrop-1.8.1-1.4.src.rpm
Summary: maildrop mail filter/mail delivery agent
Maildrop is a combination mail filter/mail delivery agent.
Maildrop reads the message to be delivered to your mailbox,
optionally reads instructions from a file how filter incoming
mail, then based on these instructions may deliver mail to an
alternate mailbox, or forward it, instead of dropping the
message into your mailbox.
Maildrop uses a structured, real, meta-programming language in
order to define filtering instructions. Its basic features are
fast and efficient. At sites which carry a light load, the
more advanced, CPU-demanding, features can be used to build
very sophisticated mail filters. Maildrop deployments have
been reported at sites that support as many as 30,000
Maildrop mailing list:
This version is compiled with support for GDBM database files,
maildir enhancements (folders+quotas), and userdb.
This is a *very* old version of maildrop - 2.0.2 is current and is vastly
improved on the old 1.x series.
However newer versions dependent on a courier-authlib package at both build and
runtime and no such package exists yet in Extras.
Additionally, fam-devel no longer exists in Core (replace that with gamin-devel)
and you might want to swap gdbm for db (--with-db=db in configure) as I find the
latter a little more reliable.
The spec definitely needs some work before it's ready for Extras (many of the
%defines are not needed or not desirable, "make install" is preferred of "make
install-strip" among others)
On the upside, I've been packaging both this and maildrop for a while now (and
courier-imap, but the spec file is a disaster area hence why I've not submitted
it) If you want to try a more modern version I'm happy to put my courier-authlib
package for review and you can build off of that.
You can also have a look at the spec if you like (it too is built off Sam's
distribution specfile but has been hacked around quite a bit since then)
I'm sorry, I meant maildrop-2.0.2.
I didn't notice any need for courier-authlib. I don't have it and am using
maildrop fine - maybe I'm not using those features? I'm only using it's mail
filtering (as a procmail alternative).
The spec file I used is from maildrop upstream with no change.
I have looked at your suggestions and made a new version:
AFAICT, courier-authlib is an optional part. Does anyone object to omitting
Mass-block FE-NEEDSPONSOR for the six review requestsÂ¹ of Neal Becker. Neal,
when you get sponsorship, you will have to unblock it for all your requests.
Â¹)Â Actually the four that do not block yet FE-NEEDSPONSOR.
(In reply to comment #3)
> AFAICT, courier-authlib is an optional part. Does anyone object to omitting
I'm currently using maildrop with courier-authlib. When a new version of
maildrop (of courier-authlib) is released I manualy build and upgrade the RPMS.
I would appreciate support for courier-authlib in this maildrop package. As far
as i know courier-authlib is not yet in FE or under review. Can I do anything to
help with that?
Does it make sense to package courier-authlib separately, or is it only a
(In reply to comment #6)
> Does it make sense to package courier-authlib separately, or is it only a
> compile-time option?
I believe packaging a separate courier-authlib makes sense. From the courier
website: "The Courier Authentication Library is a generic authentication API
that encapsulates the process of validating account passwords. (...) The Courier
authentication library must be installed before building any Courier packages
that needs direct access to mailboxes.".
Besides that, packaging courier-authlib as a seperate package for FE makes it
possible/easier to package other courier software (i.e. courier-mta org
courier-imap) for FE.
(In reply to comment #8)
> Check this:
Looks great. In comment #1 Michael proposed to submit that package for review in
Extras. Is that offer still available? Otherwise I could make this my first
package contribution to FE, but I'm pretty confident that would take more time
then when Michael puts his package up for review.
In any case, I don't think courier-authlib is a blocker for this review. The
maildrop package can always be 'improved' when/if courier-authlib becomes
available in FE.
Removing FE-NEEDSPONSOR since Neal is in cvsextras
(In reply to comment #1)
> This is a *very* old version of maildrop - 2.0.2 is current and is vastly
> improved on the old 1.x series.
> However newer versions dependent on a courier-authlib package at both build
> runtime and no such package exists yet in Extras.
> Additionally, fam-devel no longer exists in Core (replace that with
> and you might want to swap gdbm for db (--with-db=db in configure) as I find
> latter a little more reliable.
> The spec definitely needs some work before it's ready for Extras (many of
> %defines are not needed or not desirable, "make install" is preferred
> install-strip" among others)
> On the upside, I've been packaging both this and maildrop for a while now
> courier-imap, but the spec file is a disaster area hence why I've not
> it) If you want to try a more modern version I'm happy to put my
> package for review and you can build off of that.
> You can also have a look at the spec if you like (it too is built off Sam's
> distribution specfile but has been hacked around quite a bit since then)
Mike, are you going to pursue submitting this to fedora-extras?
(In reply to comment #11)
> Mike, are you going to pursue submitting this to fedora-extras?
FYI: A courier-authlib RPM is the review process now #208064
Yeah, I'll finish the review when I get a spare half hour (there's not much left
to do IIRC). I've been quite busy at work so spare time is a premium :-).
I might submit my courier-imap package once that's done, but getting it to play
nice with rpmlint could be challenging (the existing spec and upgrade methods
are... *interesting* as I try and keep Sam's way of doing things as best possible)
Then.. what is the status of this bug?
FYI: Version 2.0.3 of maildrop was released last December
Whoops. Restoring NEEDINFO for this review, as I accidently removed it
Recently procmail caused me some mail loss, and the bug is unfixable due to lack
of maintainership for the last 6 years, so I moved to maildrop. The URLs in this
report have went all bad, so I had to package from scratch.
I've placed the packages in ATrpms and would be more than willing to submit them
into Fedora. Should I take over this report or create a new one?
I'm using maildrop-2.0.2. Maybe you'd like to compare the spec file I've been
using. It is here:
(In reply to comment #18)
> I've placed the packages in ATrpms and would be more than willing to submit them
> into Fedora. Should I take over this report or create a new one?
Since this review seems to be stalled, I see no problem when you take over this report.
Axel is there any progress in maildrop package submit?
Here it is
But I think I'm supposed to reopen a new bugzilla ticket.
*** This bug has been marked as a duplicate of 241596 ***
It is now more than 1 year since I proposed adding this package and posted an
RPM for review. Since there has been no progress, I propose to resubmit this.
Here is an updated package:
Neal, this bug is closed (duplicate) since *yesterday*, when Axel Trimm has
submitted bug #241596.