I am sorry this is late. I missed this mail when it came in.
On 05/09/2016 10:16 AM, Marcus Wolschon wrote:
a)
0.75.0-20 doesn't fix ANYTHING.
It just adds a cryptic note to a NEWS file burried in /usr/share/doc .
The existing /etc/courier/maildroprc rule file is not moved (is
conversion needed?)
to /etc/maildroprc .
I agree that it's a really serious issue. Unfortunately the problem lies
with the new guy uploading the packages. Until that changes, I don't
expect this to get fixed right. You might want to start using courier
from source.
I would suggest installing apt-listbugs and apt-listchanges if you don't
already have them installed. They will help you (the admin) be more
aware of bugs, changes, and NEWS items when upgrading packages.
b)
How shall admins affected by this handle the tons of email that ended up
in/var/spool/mail/<user>
to get it delivered using the fixed maildrop rules?
courier has no command do read mailspool files and pipe them through the
delivery
pipeline.
I can't remember the exact format of the command I used to re-deliver
all of the mail.
It was something like this in a root bash shell:
for EACH in /var/spool/mail/* ; do formail -d -n 5 -s maildrop < $EACH ;
done ; unset EACH
After this, delete the old mail spool files.
The intent here is to tell formail to pipe the old messages back into
maildrop. You might need to give the full path to maildrop there. Also,
I forget the exact flags for formail. You should definitely test this on
a maildir with one one or two messages in it first before you try to
re-deliver everything. I get the feeling I forgot something important.
Beware that if you re-deliver like this all the mail mail be
re-processed (spamassassin, clamav, etc) depending on how you have your
system set up.
