Hide Forgot
Description of problem: Very latest dovecot update dovecot-2.0.16-1.fc16.i686 changes 10-master.conf to not listen on anything but loopback for non-SSL imap/pop traffic. This is done without administrators' consent or knowledge and contrary to what dovecot has done for years and one would expect it to do. Version-Release number of selected component (if applicable): dovecot-2.0.16-1.fc16.i686 How reproducible: always Steps to Reproduce: 1. update to dovecot-2.0.16-1.fc16.i686 2. restart dovecot 3. telnet 192.1.1.1 143 (insert your local ip there, but don't use 127.0.0.1) Actual results: should connect Expected results: connection refused or hangs Additional info: The offending lines in 10-master.conf are: address = localhost # allow plain imap only on localhost address = localhost # allow plain imap only on localhost comment those 2 lines out and everything works again as it did. You can enforce the same thing with iptables and sasl/pam. Yes, in theory the new way is a Good Idea(tm) but this is going to screw up a lot of people who a) use alternate protection means, b) like unencrypted imap/pop access for local wired lan users, c) haven't yet setup imaps/pops which is non-trivial.
This issue also affects dovecot-2.0.16-1.fc16.x86_64. There is nothing listed in the Changelog. No settings in my 'local.conf' would ensure port 143 was available to my local network. /etc/dovecot/conf.d/10-master.conf had to be edited and the "address =" lines commented out to return normal function. Same issue is present in the example configurations in /usr/share/doc/dovecot-2.0.16/example-config/conf.d.
Ok, when it's enabled, I get complains, when it's disabled, I get complains too :) Seems I can't satisfy all of you. > Very latest dovecot update dovecot-2.0.16-1.fc16.i686 changes > 10-master.conf to not listen on anything but loopback for non-SSL > imap/pop traffic. This is done without administrators' consent > or knowledge and contrary to what dovecot has done for years and > one would expect it to do. + > There is nothing listed in the Changelog. it is there: > * Tue Sep 13 2011 Michal Hlavinka <mhlavink> - 1:2.0.14-2 > - do not enable insecure connections by default but it seems old configuration just caused "obsolete configuration used" and only when this was fixed it started to work. Original version disabled imap/pop3 completely (but did not work correctly), new version disables them only for remote traffic. But you are right, together with the fix: > * Mon Oct 24 2011 Michal Hlavinka <mhlavink> - 1:2.0.15-2 > - do not use obsolete settings in default configuration (#743444) I should probably add, that imap/pop3 got enabled for local address. > but this is going to screw up a lot of people who XYZ... yes, there are different use cases, for some of them it's a good idea, for some of them, it's a bad idea. We can't satisfy all of them. Anyway, default configuration should be secure, that's why I agreed with those changes. This change happened in "rawhide only", but because of old type configuration used, it caused some disturbance in Fedora 16, I'm sorry for that. Anyway, I will make configuration a little bit less restricted. Now it disallows imap/pop3 completely, even TLS connections - I'll enable them in rawhide.
I am a lazy sysadmin and only read changes/manual pages when I have to! I also understand and agree with the the argument of secure by default. However, I was under the impression that "login_trusted_networks" over-rode any TLS/SSL requirements for the networks we listed in a 'local.conf'? e.g. "login_trusted_networks = 192.168.10.0/24 192.168.11.0/24" Is there a clean way of bolting down the default RPM installation, whilst we as end-users can open up what we need in a 'local.conf' without delving into the conf.d files(?); as these are likely to be over-written in any update process; and as lazy sysadmins, we may have forgotten to document what we changed! Perhaps you could include an example /etc/dovecot/local.conf, with commented out examples in the default installation? Give people a quick way of getting their server up and running, whilst encouraging them to secure it.
As a lazy sysadmin, be ready to see some outages, because bug/security fixes can cause some problems. For example VSZ limit before last update was not enforced at all(bug), so now it can break your configuration if default value is not sufficient for you. If some service is mission critical for you/your company, you should read changes and better test update in some test environment before using it in production. On the other hand, pop3/imap should not get disabled in released version, we don't do this type of changes in released versions, only in rawhide. I've tested dovecot package that is shipped in Fedora 16 (on all installation CDs/DVDs) and it logged warning about obsolete configuration used, but imap/pop3 was still disabled. So maybe it got disabled for some people only when we fixed the obsolete configuration bug, but we had to do it one way or the other and it's better to disable it for someone, because it will be noticed, than enable it for others, because it'd be much difficult to notice this. conf.d files won't get overwritten. Only if you use default config files with no changes, they'll get overwritten with new default config. But once you change config file manually, it won't get overwritten, new files with suffix ".rpmnew" will be created instead. There's no need for example local.conf, because "all the config files" are used as secure example that works out of a box.
As I wrote earlier, this is fixed in Fedora 17+ I'm not going to change configuration in released version.
*** Bug 796577 has been marked as a duplicate of this bug. ***