Your message dated Thu, 31 Aug 2006 17:35:20 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#213753: maildrop delivers to /var/spool/mail/$USER, when
$HOME/Maildir specified
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: maildrop
Version: 1.5.3-1
Severity: grave
Justification: renders package unusable
I currently have installed the courier-maildrop version of maildrop
versus the standalone. Reason being is that it works. Parsing of the
$HOME/.mailfilter works SOME of the time.
Setup == Maildrop being run as a router out of exim v4.22-5 using Andreas
Metzler's excellent setup (which works very weill with the
courier-maildrop after tweaking the /usr/bin/maildrop changing the group
to mail, changing suid to guid and adding ugo+r). It checks for
$HOME/.mailfilter and permissions properly set for /usr/bin/maildrop
to be run by $USER.
Problem == When maildrop is run (this version I am reporting against) as
the a router from exim, it parses the $HOME/.mailfilter just fine about
70% of the time. I have 'MAILDIR="$HOME/Maildir"' specified in
.mailfilter (or any user for that matter does properly) I will attach a
typical .mailfilter @ the end of this. It parses 70% of the time, but
the other 30% it just delivers the mail to /var/spool/mail/$USER. This is
extremely bad. As I have domains hosted and the all are using
maildrop to route mail properly. And since I have setup everything to
use Maildir format and all my users/domains use POP/IMAP it is not a
good problem having mail (possibly critical mail) being stored in
/var/spool/mail/$USER unavailable to the IMAP or POP.
Workaround == use courier-maildrop and tweak perms and group on
/usr/bin/maildrop. I have also tried this on 4 seperate machines
(running testing or unstable) and come up with the same issue.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux knight.gregfolkert.net 2.4.20-z1 #1 Tue Feb 4 12:56:53 EST 2003
i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages maildrop depends on:
ii exim4-daemon-heavy [mail-t 4.22-5 Exim (v4) with extended features,
ii libc6 2.3.2-7 GNU C Library: Shared libraries an
ii libgcc1 1:3.3.2-0pre4 GCC support library
ii libgdbm3 1.8.3-2 GNU dbm database routines (runtime
ii libstdc++5 1:3.3.2-0pre4 The GNU Standard C++ Library v3
# .Mailfilter - rules for maildrop
MAILDIR="/home/greg/Maildir"
# First, catch all spam and divert to junk folder
if (/^X-Spam-Flag: YES$/)
to $MAILDIR/.junk-spam
# Mailing lists, in approximate descending order of volume
if (/^List-Id: <debian-user.lists.debian.org>$/)
to $MAILDIR/.Debian-User
if (/^List-Id: <debian-devel.lists.debian.org>$/)
to $MAILDIR/.Debian-Devel
if (/^List-Id: <debian-testing.lists.debian.org>$/)
to $MAILDIR/.Debian-Testing
if (/^List-Id: <debian-alpha.lists.debian.org>$/)
to $MAILDIR/.Debian-Alpha
if (/^List-Id: <debian-boot.lists.debian.org>$/)
to $MAILDIR/.Debian-Boot
if (/^List-Id: An experiment in MUA-based list moderation
<linux-elitists.zgp.org>$/)
to $MAILDIR/.Elitists
if (/^List-Id: A user list for the exim MTA <exim-users.exim.org>$/)
to $MAILDIR/.Eximlist
if (/^List-Id: General questions regarding Samba <samba.lists.samba.org>$/)
to $MAILDIR/.Sambalist
if (/^List-Id: The OpenBIOS Mailinglist <openbios.lists.openbios.org>$/)
to $MAILDIR/.OpenBios-Org
if (/^List-Id: IWETHEY Mailing List$/)
to $MAILDIR/.IWE
if (/^From: root <[EMAIL PROTECTED]>$/)
to $MAILDIR/.AllWAMNotices
--- End Message ---
--- Begin Message ---
tag 213753 unreproducible
thanks
On Thu, Aug 31, 2006 at 10:44:52AM -0400, Greg Folkert wrote:
> > > Getting back to the point though, I can install "maildrop" and see what
> > > still occurs. This would be on Sarge currently.
> > >
> > > I might be able to force a different newer version if you think it might
> > > help. I'd have to give a heads up to my users, to allow them to cope.
> >
> > I wouldn't insist on it, given that it's a production system. And since
> > sarge still has the old 1.5.x version, if we found anything concrete,
> > you'd still have to upgrade half of etch/sid to get an updated maildrop.
> > So I'm thinking - let's close this as an unreproducible bug, and next
> > time you upgrade your system and have an already announced downtime,
> > try maildrop and see how it works out, and file a new bug report.
> > Would that be okay?
>
> That would be fine. I'd just assume to reduce the long-term bug count as
> to go through the pain right now of doing a half upgrade. So yeah, file
> it as unreproducible/"more info" type of thing.
Okay, this mail will accomplish that.
> I am installing a new machine Friday that will be a SID+Experimental
> machine. It will be mainly for personal use but in production... but
> still, I might be able to move a few trusted users to the machine for
> testing.
>
> If I find problems, I'd rather file a new report, as I could get more
> info for it, maybe even let you have a login to do some testing or
> forensics.
>
> Once again, thanks for your efforts with Debian, I really appreciate the
> hard work.
No problem. Thanks for your patience.
--
2. That which causes joy or happiness.
--- End Message ---
