Bug#822071: maildrop: Upgrade from courier-maildrop: Default delivery location changed from Maildirs $/HOME/Maildir to /var/mail/$USER
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ý
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/
> > 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.
>
>
Bug#822071: maildrop: Upgrade from courier-maildrop: Default delivery location changed from Maildirs $/HOME/Maildir to /var/mail/$USER
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/ 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.
Bug#822071: maildrop: Upgrade from courier-maildrop: Default delivery location changed from Maildirs $/HOME/Maildir to /var/mail/$USER
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 . b) How shall admins affected by this handle the tons of email that ended up in /var/spool/mail/ to get it delivered using the fixed maildrop rules? courier has no command do read mailspool files and pipe them through the delivery pipeline.
Processed: Re: Bug#822071: maildrop: Upgrade from courier-maildrop: Default delivery location changed from Maildirs $/HOME/Maildir to /var/mail/$USER
Processing control commands: > reassign -1 courier-maildrop 0.75.0-15 Bug #822071 [maildrop] maildrop: Upgrade from courier-maildrop: Default delivery location changed from Maildirs $/HOME/Maildir to /var/mail/$USER Bug reassigned from package 'maildrop' to 'courier-maildrop'. No longer marked as found in versions maildrop/2.8.3-0.1. Ignoring request to alter fixed versions of bug #822071 to the same values previously set Bug #822071 [courier-maildrop] maildrop: Upgrade from courier-maildrop: Default delivery location changed from Maildirs $/HOME/Maildir to /var/mail/$USER Marked as found in versions courier/0.75.0-15. -- 822071: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822071 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#822071: maildrop: Upgrade from courier-maildrop: Default delivery location changed from Maildirs $/HOME/Maildir to /var/mail/$USER
Control: reassign -1 courier-maildrop 0.75.0-15 Hi, Disclaimer: I'm neither the maintainer of courier nor maildrop, but a package of mine suggests maildrop. On Wed, Apr 20, 2016 at 05:14:07PM -0700, J Mo wrote: > Recently I decided to upgrade courier (mta and imap) on one of my > mail servers. It was a disaster. The quality of these packages is > abysmal and dangerous. This is one of the many serious, grave, and > critical bugs I ran into during that process. > > > > It appears that the default mail delivery location in > maildrop/courier-maildrop has changed from being Maildirs > ($HOME/Maildir) to spool files (/var/mail/). > > Upon upgrading my courier system, I found that new mail was being > delivered to mailspool files in /var/mail instead of Maildirs, as it > was previously. > > I don't know why this change has happened as I don't have much time > to look into it, but it is definitely a default behavior change. > This could definiely lead to data loss, and at the very least will > be a pain if the admin has re-deliver the mail spool contents back > to the Maildirs. > > A workaround is to configure the new /etc/maildroprc file DEFAULT > parameter, which is convinently already typed out with the correct > arguments and just needs to be uncommented. courier 0.75.0-15 dropped the duplicate courier-maildrop and just started to depend on maildrop, cf: * Kill duplicate courier-maildrop package and just depend on standard maildrop package (Closes: #289091, #193650, #567462, #684230) As such maybe courier should ship a NEWS entries indicating that there might be some needed changes to /etc/maildroprc. Regards, Salvatore
Bug#822071: maildrop: Upgrade from courier-maildrop: Default delivery location changed from Maildirs $/HOME/Maildir to /var/mail/$USER
Package: maildrop Version: 2.8.3-0.1 Severity: grave Justification: causes non-serious data loss Recently I decided to upgrade courier (mta and imap) on one of my mail servers. It was a disaster. The quality of these packages is abysmal and dangerous. This is one of the many serious, grave, and critical bugs I ran into during that process. It appears that the default mail delivery location in maildrop/courier-maildrop has changed from being Maildirs ($HOME/Maildir) to spool files (/var/mail/). Upon upgrading my courier system, I found that new mail was being delivered to mailspool files in /var/mail instead of Maildirs, as it was previously. I don't know why this change has happened as I don't have much time to look into it, but it is definitely a default behavior change. This could definiely lead to data loss, and at the very least will be a pain if the admin has re-deliver the mail spool contents back to the Maildirs. A workaround is to configure the new /etc/maildroprc file DEFAULT parameter, which is convinently already typed out with the correct arguments and just needs to be uncommented. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages maildrop depends on: ii courier-authlib 0.66.4-7 ii libc62.22-7 ii libcourier-unicode1 1.4-2 ii libgcc1 1:5.3.1-14 ii libgdbm3 1.8.3-13.1 ii libpcre3 2:8.38-3.1 ii libstdc++6 5.3.1-14 Versions of packages maildrop recommends: ii courier-mta [mail-transport-agent] 0.75.0-18 maildrop suggests no packages. -- Configuration Files: /etc/maildroprc changed: DEFAULT="$HOME/Maildir" -- no debconf information
