After further investigation this seems to be the problem.
Originally the dovecot-core postinst created self-signed ssl certificates and modified /etc/dovecot/conf.d/10-ssl.conf to enable them. ucf managed upgrades to these files.
As of 2.2.13-6 we stopped doing that. However this meant that new users who did not have certs got an error because dovecot tries to use the non-existent certificate.
So in 2.2.13-7 the configuration is shipped with the ssl cert location bits commented out. Now new users and anyone who has modified the locations in ssl_cert and ssl_key can successfully install or upgrade. But people like you have a 10-ssl.conf that looks exactly like the default one in -6. So apparently ucf thinks you haven't modified the default configuration and blindly installs the new configuration on top of it.
I don't know if that should be considered a bug in ucf but the workaround in dovecot-cores postinst I am thinking of is to check the values of ssl_cert and ssl_key and see if there are actually files there and if so, avoid commenting them out or maybe it will be simple to change the value of the ssl parameter to no by default. (It seems obvious but I have a nagging feeling it might not work. I'll experiment.)
-- Jaldhar H. Vyas <jald...@debian.org> -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
