Marcus,
I have now added a critical debconf prompts, so nobody installing it
won't miss the notices.
Here's one related to courier:courier user change:
--cut here--
Template: courier-base/courier-user
Type: note
_Description: Courier MTA under courier user
The Courier MTA packaging has been extensively rewritten and major
changes had been done to the default setup of Courier MTA.
.
The default user and group for Courier MTA has been changed to
courier:courier. The package tries hard to make all files belong to
correct user:group and the permissions on those files are correct,
but if you have a non-default setup, you will have to make sure that:
.
+ All file owners and file in /etc/courier and /var/lib/courier
are correctly set.
+ MAILUSER and MAILGROUP settings in /etc/courier/esmtpd is set to
correct user and group, both has to be set to `courier'.
--cut here--
And second about courier-maildrop -> maildrop change:
--cut here--
Template: courier-maildrop/deprecated
Type: note
_Description: courier-maildrop replaced with maildrop
The courier-maildrop package is now just a dummy package that depends
on regular maildrop package.
.
The new maildrop configuration is located in the /etc/maildroprc file
and you'll have to reconfigure it, so your email doesn't get delivered
to invalid location.
.
Any previous configuration has been left in the /etc/courier/maildroprc
.
Default mail deliver location in the maildrop package is
/var/spool/mail
and to change it back again to ~/Maildrop you need to uncomment
following
line in the /etc/maildroprc:
.
DEFAULT="$HOME/Maildir"
.
If you have configured courierd to deliver mail using maildrop,
you'll need to add '-d "${RECIPIENT}"' to your DEFAULTDELIVERY
configuration in /etc/courier/courierd, f.e.:
.
DEFAULTDELIVERY='|/usr/bin/maildrop -w 90 -V 1 -d "${RECIPIENT}"'
.
If you are unsure you want to continue, please abort the installation
now using Ctrl-C and prepare for the upgrade by changing the
configuration before the installation. To resume the installation,
run:
.
dpkg --configure --pending
--cut here--
I would actually welcome improvements on the technical details if you
have any constructive remarks how to improve the experience.
Cheers,
--
Ondřej Surý <[email protected]>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Potřeby pro pečení chleba
všeho druhu
On Mon, May 23, 2016, at 04:31, J Mo wrote:
>
> 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.
>
>
