Re: sieve stopped working and doveadm mailbox list without -s shows less folders then with

[Timo Sirainen]

On 7 Sep 2017, at 17.42, Ralf Becker  wrote:
> 
> Dovecot 2.2.31 with mailboxes in mdbox format.
> 
> Since a couple of days some mailboxes have the problem, that sieve rules
> moving mails to folders stop working and .sieve.log in mailbox shows:
> 
> sieve: info: started log at Sep 07 13:57:17.
> error:
> msgid=<20170907155704.egroupware.s4ythvjrr12wsijlpkbk...@somedomain.egroupware.de>:
> failed to store into mailbox 'INBOX/Munser': Mailbox doesn't exist:
> INBOX/Munser.
> 
> When I do a doveadm mailbox list -s -u @ I get all folders
> incl. the one mentioned above, while doveadm mailbox list without -s
> shows just
> user
> INBOX

Subscriptions are stored independently from the actual folders. So it looks 
like the subscription file exists and is correct, but somehow you've lost all 
the folders. Do you see the folders in the filesystem under user/mailboxes/ 
directory? My guess is that it only has INBOX, which means the folders were 
deleted by something (Dovecot corruption can't lose entire folders - something 
must explicitly delete them).

Re: What INTERNALDATE does dovecot with mbox storage set on a COPY'd message?

[Steinar Bang]

> Aki Tuomi :

> On 09.09.2017 12:33, Steinar Bang wrote:
>> When a message is copied to a folder on dovecot with mbox storage, is
>> the mtime of the saved mbox file set to the time of the save?  
[snip!]
> Internaldate is picked from the separating 'From' line in mbox file.

> "From u...@example.org Thu Oct 20 18:44:06 2016"

Sorry! I mistyped: I meant maildir, not mbox.

So, to repeat the question:

When a message is copied to a folder on dovecot with maildir storage, is
the mtime of the saved maildir file set to the time of the save?

Or is the mtime set to the Date: field of the source message that is
saved?

If there is a difference in the behaviour, do someone know the dovecot
version number where the change happened?

The reason I'm asking is a problem reported on the Gnus imap client in
August 2016, where messaged moved by Gnus showed up with the wrong order
and/or wrong date in other imap clients.

(The reason for the different message ordering was that the other clients
use the INTERNALDATE and that was changed to the time of message move
when Gnus was used. Gnus use the Date of the source message)

[RFC master-2.2 1/1] Support setting min/max SSL protocol version

[Apollon Oikonomopoulos]

OpenSSL 1.1 exposes a new API for setting the minimum and maximum
supported SSL protocol version, using SSL_CTX_set_min_proto_version and
SSL_CTX_set_max_proto_version respectively. The main difference with the
old SSL_CTX_set_options API is that the new API can either restrict or
relax the library defaults; the old API could only be used to
selectively disable protocols (but not enable what might have been
disabled by default).

The new API allows distributions and vendors to ship OpenSSL versions
with stricter run-time defaults (e.g. TLSv1.2-only), while still
allowing applications to enable older protocols (e.g. TLSv1) when
dealing with legacy clients.

To support the new API, we add two new config file options,
ssl_min_proto_version and ssl_max_proto_version. These settings are only
effective when built against OpenSSL 1.1. Also, dovecot will issue a
warning if the old-style ssl_options config file option is encountered
while running on OpenSSL 1.1 (although it will not ignore the option at
this point).

Signed-off-by: Apollon Oikonomopoulos 
---
 doc/example-config/conf.d/10-ssl.conf  |  4 
 src/config/config-parser.c | 25 +
 src/lib-master/master-service-ssl-settings.c   |  4 
 src/lib-master/master-service-ssl-settings.h   |  2 ++
 src/lib-master/master-service-ssl.c|  2 ++
 src/lib-ssl-iostream/iostream-openssl-common.c | 12 +++
 src/lib-ssl-iostream/iostream-openssl.h|  1 +
 src/lib-ssl-iostream/iostream-ssl.h|  2 ++
 src/login-common/ssl-proxy-openssl.c   | 30 ++
 9 files changed, 82 insertions(+)

diff --git a/doc/example-config/conf.d/10-ssl.conf 
b/doc/example-config/conf.d/10-ssl.conf
index cf651c252..aceae233a 100644
--- a/doc/example-config/conf.d/10-ssl.conf
+++ b/doc/example-config/conf.d/10-ssl.conf
@@ -47,6 +47,10 @@ ssl_key = 
 #include 
 #include 
+#include 
 #ifdef HAVE_GLOB_H
 #  include 
 #endif
@@ -419,6 +420,11 @@ config_all_parsers_check(struct config_parser_context *ctx,
struct master_service_settings_output output;
unsigned int i, count;
const char *ssl_set, *global_ssl_set;
+#if OPENSSL_VERSION_NUMBER >= 0x1010
+   const char *ssl_protocols;
+#else
+   const char *ssl_min_proto_version, *ssl_max_proto_version;
+#endif
pool_t tmp_pool;
bool ssl_warned = FALSE;
int ret = 0;
@@ -454,6 +460,25 @@ config_all_parsers_check(struct config_parser_context *ctx,
ssl_warned = TRUE;
}
 
+#if OPENSSL_VERSION_NUMBER >= 0x1010
+   ssl_protocols = get_str_setting(parsers[i], "ssl_protocols", 
"");
+   if (*ssl_protocols != '\0')
+   i_warning("ssl_protocols is deprecated and will be "
+ "ignored in future versions when running "
+ "with OpenSSL 1.1. Please use "
+ "ssl_min_proto_version and "
+ "ssl_max_proto_version instead.");
+#else
+   ssl_min_proto_version = get_str_setting(parsers[i],
+   "ssl_min_proto_version", "");
+   ssl_max_proto_version = get_str_setting(parsers[i],
+   "ssl_max_proto_version", "");
+   if ((*ssl_min_proto_version != '\0') ||
+   (*ssl_max_proto_version != '\0'))
+   i_warning("ssl_*_proto_version ignored, "
+ "not supported by OpenSSL");
+#endif
+
ret = config_filter_parser_check(ctx, tmp_parsers, error_r);
config_filter_parsers_free(tmp_parsers);
p_clear(tmp_pool);
diff --git a/src/lib-master/master-service-ssl-settings.c 
b/src/lib-master/master-service-ssl-settings.c
index 2487c8369..484022618 100644
--- a/src/lib-master/master-service-ssl-settings.c
+++ b/src/lib-master/master-service-ssl-settings.c
@@ -24,6 +24,8 @@ static const struct setting_define 
master_service_ssl_setting_defines[] = {
DEF(SET_STR, ssl_key_password),
DEF(SET_STR, ssl_cipher_list),
DEF(SET_STR, ssl_protocols),
+   DEF(SET_STR, ssl_min_proto_version),
+   DEF(SET_STR, ssl_max_proto_version),
DEF(SET_STR, ssl_cert_username_field),
DEF(SET_STR, ssl_crypto_device),
DEF(SET_BOOL, ssl_verify_client_cert),
@@ -53,6 +55,8 @@ static const struct master_service_ssl_settings 
master_service_ssl_default_setti
 #else
.ssl_protocols = "!SSLv3",
 #endif
+   .ssl_min_proto_version = "",
+   .ssl_max_proto_version = "",
.ssl_cert_username_field = "commonName",
.ssl_crypto_device = "",
.ssl_verify_client_cert = FALSE,
diff --git a/src/lib-master/master-service-ssl-settings.h 
b/src/lib-master/master-service-ssl-settings.h
index a4157d3ef..0fc9aa9ca 100644
--- 

[RFC master-2.2 0/1] Support OpenSSL 1.1 API for setting allowed TLS versions

[Apollon Oikonomopoulos]

Hi,

I came up with the following patch while trying to figure out a good solution
for the situation described in Debian bug #871987[1]. In short, OpenSSL in
Debian unstable has disabled TLSv1.0 and TLSv1.1 *by default*. That means that
unless an application requests otherwise, only TLSv1.2 is supported. In the
world of e-mail this is seemingly an issue, as there are still way too many old
clients out there supporting only TLSv1 or TLSv1.1.

Now, traditionally OpenSSL 0.9.8/1.0 used SSL_CTX_set_options() to allow
*disabling* specific protocols, without offering a way to enable previously
disabled protocols. OpenSSL 1.1 introduced a dedicated API[2] to set allowed
protocol versions, taking a linear version approach: the application may
request a minimum and a maximum allowed version (inclusive), allowing all
versions inbetween as well.

Dovecot's existing ssl_protocols option is probably not ideal to use with this
new "linear" model. Instead, I introduced two new options,
ssl_min_proto_version and ssl_max_proto_version, that map directly to OpenSSL
1.1 concepts.

I have tested the patch with both OpenSSL 1.0 and OpenSSL 1.1. With OpenSSL 1.1
it works as expected; with OpenSSL 1.0 it doesn't seem to break anything. Other
than that, this is a first version; I'm sure there are still things to improve,
so comments are welcome :)

Regards,
Apollon

[1] https://bugs.debian.org/871987
[2] https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_min_proto_version.html

Apollon Oikonomopoulos (1):
  Support setting min/max SSL protocol version

 doc/example-config/conf.d/10-ssl.conf  |  4 
 src/config/config-parser.c | 25 +
 src/lib-master/master-service-ssl-settings.c   |  4 
 src/lib-master/master-service-ssl-settings.h   |  2 ++
 src/lib-master/master-service-ssl.c|  2 ++
 src/lib-ssl-iostream/iostream-openssl-common.c | 12 +++
 src/lib-ssl-iostream/iostream-openssl.h|  1 +
 src/lib-ssl-iostream/iostream-ssl.h|  2 ++
 src/login-common/ssl-proxy-openssl.c   | 30 ++
 9 files changed, 82 insertions(+)

-- 
2.14.1

Re: disable imap for ldap user

[Markus Rosjat]

Hi steffen,

my arg is telexNumber and I basically use it the wrong way here but I 
have to migrate some stuff and before I start to invent things I like to 
try to set it up like before. In courier you could define that a given 
arg from LDAP sets the option disableimap to 1 or 0 so I was looking for 
a way to do that in dovecot.



Am 13.09.2017 um 14:49 schrieb Steffen Kaiser:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 9 Sep 2017, Markus Rosjat wrote:

In general every user can use pop3 but only a few can use imap so what 
I want is:


- permit pop3 by default
- check if the attribute is 0 or 1
- depending on the result a user can login with imap protocol


What's the name of the attribute? Maybe you can use %s in the the 
pass_filter string. If the name does not contain "imap", you need to 
change the logic, e.g. invent a general LDAP attribute deniedService

and set deniedServer=imap

Or AllowedService=imap allowedService=pop3
Or DeniedIMAP=1


Am 08.09.2017 um 17:59 schrieb Ralph Seichter:

On 08.09.2017 17:11, Markus Rosjat wrote:


I have a LDAP dir with an attribute set to 0 or 1 and in my old setup
(a courier server) I used this attribute to map it to an authoption
called disableimap. This prevent users to access the mailbox with imap
protocol.

So the question is what should I set in dovecot to get the same
behaviour?


You can configure 'pass_filter' to discount entries with your disable-
flag. Affected users won't be able to authenticate with Dovecot, which
I assume is what you are trying to achieve.

-Ralph






- -- Steffen Kaiser
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEVAwUBWbkpYHz1H7kL/d9rAQJ8kwgAo2PMSAmZ4fwld7Qw9Cw+2Htq42CbaRPK
8qtJTy61lF++VSGrsfy3ed4DGuaDrWM1IFo3/BifJusdjAgCxQqKQFV6J29HvyNa
SCeF5BHTvgC4owMXt5HGrdIIU872oKI8vHCkmO3i8dwuWZTg5t+QO/iKLI3yGUa7
6D1pEqydGOU1KXYO/KxjHmYWvZ7Iv8Mt3eJ6yucC1xtxPVGRD+6gOZn12p3d/srb
ZGYqXyaQ0UQXV+8skQTMCrr+YbNxjN6aSxZOIcDxLjCVeJrnBCe5KJaLp+MU35Z8
yiWmF+dVByX3RxzmPiuRLEoMpiTEOfr2jzSwzzdiTVt5ViGekIwZ6g==
=rlq8
-END PGP SIGNATURE-


--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before 
you print it, think about your responsibility and commitment to the 
ENVIRONMENT

Re: Problems to configure IMAP Quota

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 8 Sep 2017, Jacques Belin wrote:


1) It seems that when we use the sql dict, a map contaning the patern
"priv/quota/limit/messages" is mandatory. Not specifying it  in
dovecot-dict-sql.conf.ext issues an error.  As we are interested only by
the storage size and don't want to process the number of messages, how
to get rid of it ?


No, not that I know of. The value is calculated and storred.


2) We store the storage value in kilobytes.
But the plugin seems to only accept storage in bytes, Is there any way
to let know to dovecot that the value stored in the database is in
kilobytes ? (of course, I tried to put "size/1024" in the value_field
field of the map. It works, but generate a lot of error lines in the
dovecot log as it create a syntaxly incorrect MySQL uodate request...)


The plugin maintains an internal value in a dict. Don't change it and 
keep your hands off.
If you need to access the current values from the DB, use a view, which 
transforms the internal value into what you need.


The limits can be expressed in any way, have your userdb query calculate 
bytes from whatever value you have in the userdb.


For:


We manage a mail server using Dovecot under Debian.
Since a long time, we run nightly a script permitting to display the
storage usage of each user on the webmail, using internal calls. The
usage on each mailbox is stored in a Mysql database.


use doveadm to get the values and modify them. If the VIEW does not fit.

- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEVAwUBWbkvoHz1H7kL/d9rAQLQCQf/c11sxz+iDZM7K5Sj4aNb/jLwewXcijRX
LsnOkqfH422Ranue3EA4zBROPHrkTd+82txYQ4NlmJc8QN2Fp+td5Ksz0Jz64X9O
41l8JBIQmQ45F9wA1X4Eu8pIAxJ841DTq5AeAVh5MNlTtcIc1svnLWxPVuqlxd1B
Yt6XpkEHwoTJEt9G/kFKjzuuLLpJJn3r/y2O7BtdBbWRT5DGm5NafwxxRoUpWv94
jxcY7SlifFH7prvehUqnYU4cJiyzGMt+vetYOjM0IFhMbKSM3Y0cFuF/wNUFa/Vv
+/jCciVmw0LLPlhKpBnVaF3HMV+lqoTgRYgA6nV0tlfLPh4SmEjGFA==
=rqXt
-END PGP SIGNATURE-

Re: concering dovecot logging

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 11 Sep 2017, Rajesh M wrote:


had a question concerning dovecot lda logging.

deliver_log_format = From:<%f>-<%e> :: Subject:<%s> :: Status:<%$> ::
MsgID:<%m> :: Size<%p> :: vSize<%w>

am getting %e ie envelope sender as MAILER-DAEMON in the logs

Sep 11 08:35:50 lda(n...@xxx.com): Info: sieve: From:- :: Subject: :: Status:> :: 
MsgID:<> :: Size<12497> :: vSize<12687>

what could be the reason ?


Well, what was the original envelope from if MAILER-DAEMON is wrong ?
Was this message forwarded to nocforw...@y.com by a sieve script and 
not spooled?


- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEVAwUBWbktkXz1H7kL/d9rAQLECgf+Nwx+XaFxBIJfnoqN1xsjN1XD9GAkDHY0
qKexrii8DQYMx/VeyYfUuMzRIvI0nlvCtDKB6MSOWYFpPf/sKcppdNMHT1zs75HO
HfOh8yLvAqePEfzBj5vaZ2R6qG4ZhjROtJhXt5hVfqcaGbsa5jcZ2gQ2Dnf4oaiZ
AjBzVQrGddkGGjkB0ob3xP0UUfknMHAgvNFLM/iWHYRcJuOUYvDhzLIqAYcf+CLB
UMJIZKfGJZAq44Xx6nKrv+uv/lg3LCiiC8dVdWRy1MVq4kx1p56arpyhtZqA3qoV
FGynDQz3X+oReZW6LPz5YYT/1DEkhmQ/nA0bnXYlfxdLPbVtVgaBpA==
=es33
-END PGP SIGNATURE-

Re: Problem w/ Dovecot authentication against AD

[Garry Glendown]

> You need to disable referral following in /etc/ldap/ldap.conf (or
> whatever applies to your system)
I had found that option ("referrals off") earlier, but it didn't work -
while doing more (new) tcpdumps, I noticed the result format had
changed, which reminded me that I had changed LDAP to version 2 during
my extended attempts to get it to work ... after switching back to
version 3, the authentication finally worked!!!

Thanks, -garry

-- 
PGP Fingerprint: A79F A33F 5B13 BEB7 A51D 274F F99C 3AE2 4BCB 7015

Re: disable imap for ldap user

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 9 Sep 2017, Markus Rosjat wrote:

In general every user can use pop3 but only a few can use imap so what I want 
is:


- permit pop3 by default
- check if the attribute is 0 or 1
- depending on the result a user can login with imap protocol


What's the name of the attribute? Maybe you can use %s in the the 
pass_filter string. If the name does not contain "imap", you need to 
change the logic, e.g. invent a general LDAP attribute deniedService

and set deniedServer=imap

Or AllowedService=imap allowedService=pop3
Or DeniedIMAP=1


Am 08.09.2017 um 17:59 schrieb Ralph Seichter:

On 08.09.2017 17:11, Markus Rosjat wrote:


I have a LDAP dir with an attribute set to 0 or 1 and in my old setup
(a courier server) I used this attribute to map it to an authoption
called disableimap. This prevent users to access the mailbox with imap
protocol.

So the question is what should I set in dovecot to get the same
behaviour?


You can configure 'pass_filter' to discount entries with your disable-
flag. Affected users won't be able to authenticate with Dovecot, which
I assume is what you are trying to achieve.

-Ralph






- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEVAwUBWbkpYHz1H7kL/d9rAQJ8kwgAo2PMSAmZ4fwld7Qw9Cw+2Htq42CbaRPK
8qtJTy61lF++VSGrsfy3ed4DGuaDrWM1IFo3/BifJusdjAgCxQqKQFV6J29HvyNa
SCeF5BHTvgC4owMXt5HGrdIIU872oKI8vHCkmO3i8dwuWZTg5t+QO/iKLI3yGUa7
6D1pEqydGOU1KXYO/KxjHmYWvZ7Iv8Mt3eJ6yucC1xtxPVGRD+6gOZn12p3d/srb
ZGYqXyaQ0UQXV+8skQTMCrr+YbNxjN6aSxZOIcDxLjCVeJrnBCe5KJaLp+MU35Z8
yiWmF+dVByX3RxzmPiuRLEoMpiTEOfr2jzSwzzdiTVt5ViGekIwZ6g==
=rlq8
-END PGP SIGNATURE-

Re: Problem w/ Dovecot authentication against AD

[mj]

Hi,

Perhaps you need auth_bind = yes?

MJ

On 09/13/2017 01:34 PM, Garry Glendown wrote:

Hi,

I had to start using Dovecot on a machine as the new OS does not come
with Cyrus IMAP anymore. After multiple problems, I managed to get
everything working, including LDAP authentication against the (old)
Novell LDAP server.
Anyway, the authentication is supposed to be migrated to the new Windows
AD. For other tools, I successfully migrated the config to use AD, but
somehow Dovecot does not work as it should.

I've been going back and forth, trying everything I could think of, but
still can't get it to work.

Here's the excerpt from the config file:

hosts = 10.10.10.210
uris = ldap://10.10.10.210:389
dn = cn=Administrator,cn=Users,dc=srv,dc=SLD,dc=net
dnpass = PASSWORD
tls = no
debug_level = -1
auth_bind = yes
ldap_version = 3
base = DC=srv,dc=SLD,dc=net
deref = never
scope = subtree
user_attrs =  sAMAccountName=user
user_filter = (&(sAMAccountName=%n)(objectclass=person))
pass_attrs = sAMAccountName=user
pass_filter = (&(sAMAccountName=%n)(objectclass=person))
iterate_attrs = mail=user
iterate_filter = (objectclass=person)
default_pass_scheme = PLAIN

The problem might be caused by the referal-info sent by the AD, which I
can see both in the results dovecot gets (checked with tcpdump), as well
as in ldapsearch ... apart from the actual search result, I always get
three additional results:

#
refldap://DomainDnsZones.srv.SLD.net/DC=DomainDnsZones,DC=srv,DC=SLD,DC=net

#
refldap://ForestDnsZones.srv.SLD.net/DC=ForestDnsZones,DC=srv,DC=SLD,DC=net

# refldap://srv.SLD.net/CN=Configuration,DC=srv,DC=SLD,DC=net

 From what I can see in the pcap as well as some of the logs, dovecot
binds to the AD, sends out the LDAP query correctly, gets the lookup
result with the user queried plus the above three referrals, then
unbinds from the (named) bind, attempts a simple bind without dn/dnpass
(multiple times), and finally sends three additional search requests
under the search bases

cn=Configuration,DC=srv,DC=SLD,DC=net
DC=ForestDnsZones,DC=srv,DC=SLD,DC=net
DC=DomainDnsZones,DC=srv,DC=SLD,DC=net

These three requests are denied by the AD as they are not permitted
without a successful prior bind.
Dovecot then fails the auth process.

Is there a way to stop Dovecot from using the referals? Openldap seems
to have an option to disable referals, but Dovecot does not allow that
option in its LDAP config, and having the option set in the global
ldap.conf doesn't seem to help any, either. Is there possibly a way to
disable the referal information on the AD side?

Thanks, Garry

Re: Problem w/ Dovecot authentication against AD

[Aki Tuomi]

You need to disable referral following in /etc/ldap/ldap.conf (or
whatever applies to your system)

Aki

On 13.09.2017 14:34, Garry Glendown wrote:
> Hi,
>
> I had to start using Dovecot on a machine as the new OS does not come
> with Cyrus IMAP anymore. After multiple problems, I managed to get
> everything working, including LDAP authentication against the (old)
> Novell LDAP server.
> Anyway, the authentication is supposed to be migrated to the new Windows
> AD. For other tools, I successfully migrated the config to use AD, but
> somehow Dovecot does not work as it should.
>
> I've been going back and forth, trying everything I could think of, but
> still can't get it to work.
>
> Here's the excerpt from the config file:
>
> hosts = 10.10.10.210
> uris = ldap://10.10.10.210:389
> dn = cn=Administrator,cn=Users,dc=srv,dc=SLD,dc=net
> dnpass = PASSWORD
> tls = no
> debug_level = -1
> auth_bind = yes
> ldap_version = 3
> base = DC=srv,dc=SLD,dc=net
> deref = never
> scope = subtree
> user_attrs =  sAMAccountName=user
> user_filter = (&(sAMAccountName=%n)(objectclass=person))
> pass_attrs = sAMAccountName=user
> pass_filter = (&(sAMAccountName=%n)(objectclass=person))
> iterate_attrs = mail=user
> iterate_filter = (objectclass=person)
> default_pass_scheme = PLAIN
>
> The problem might be caused by the referal-info sent by the AD, which I
> can see both in the results dovecot gets (checked with tcpdump), as well
> as in ldapsearch ... apart from the actual search result, I always get
> three additional results:
>
> #
> refldap://DomainDnsZones.srv.SLD.net/DC=DomainDnsZones,DC=srv,DC=SLD,DC=net
>
> #
> refldap://ForestDnsZones.srv.SLD.net/DC=ForestDnsZones,DC=srv,DC=SLD,DC=net
>
> # refldap://srv.SLD.net/CN=Configuration,DC=srv,DC=SLD,DC=net
>
> From what I can see in the pcap as well as some of the logs, dovecot
> binds to the AD, sends out the LDAP query correctly, gets the lookup
> result with the user queried plus the above three referrals, then
> unbinds from the (named) bind, attempts a simple bind without dn/dnpass
> (multiple times), and finally sends three additional search requests
> under the search bases
>
>cn=Configuration,DC=srv,DC=SLD,DC=net
>DC=ForestDnsZones,DC=srv,DC=SLD,DC=net
>DC=DomainDnsZones,DC=srv,DC=SLD,DC=net
>
> These three requests are denied by the AD as they are not permitted
> without a successful prior bind.
> Dovecot then fails the auth process.
>
> Is there a way to stop Dovecot from using the referals? Openldap seems
> to have an option to disable referals, but Dovecot does not allow that
> option in its LDAP config, and having the option set in the global
> ldap.conf doesn't seem to help any, either. Is there possibly a way to
> disable the referal information on the AD side?
>
> Thanks, Garry
>

Problem w/ Dovecot authentication against AD

[Garry Glendown]

Hi,

I had to start using Dovecot on a machine as the new OS does not come
with Cyrus IMAP anymore. After multiple problems, I managed to get
everything working, including LDAP authentication against the (old)
Novell LDAP server.
Anyway, the authentication is supposed to be migrated to the new Windows
AD. For other tools, I successfully migrated the config to use AD, but
somehow Dovecot does not work as it should.

I've been going back and forth, trying everything I could think of, but
still can't get it to work.

Here's the excerpt from the config file:

hosts = 10.10.10.210
uris = ldap://10.10.10.210:389
dn = cn=Administrator,cn=Users,dc=srv,dc=SLD,dc=net
dnpass = PASSWORD
tls = no
debug_level = -1
auth_bind = yes
ldap_version = 3
base = DC=srv,dc=SLD,dc=net
deref = never
scope = subtree
user_attrs =  sAMAccountName=user
user_filter = (&(sAMAccountName=%n)(objectclass=person))
pass_attrs = sAMAccountName=user
pass_filter = (&(sAMAccountName=%n)(objectclass=person))
iterate_attrs = mail=user
iterate_filter = (objectclass=person)
default_pass_scheme = PLAIN

The problem might be caused by the referal-info sent by the AD, which I
can see both in the results dovecot gets (checked with tcpdump), as well
as in ldapsearch ... apart from the actual search result, I always get
three additional results:

#
refldap://DomainDnsZones.srv.SLD.net/DC=DomainDnsZones,DC=srv,DC=SLD,DC=net

#
refldap://ForestDnsZones.srv.SLD.net/DC=ForestDnsZones,DC=srv,DC=SLD,DC=net

# refldap://srv.SLD.net/CN=Configuration,DC=srv,DC=SLD,DC=net

>From what I can see in the pcap as well as some of the logs, dovecot
binds to the AD, sends out the LDAP query correctly, gets the lookup
result with the user queried plus the above three referrals, then
unbinds from the (named) bind, attempts a simple bind without dn/dnpass
(multiple times), and finally sends three additional search requests
under the search bases

   cn=Configuration,DC=srv,DC=SLD,DC=net
   DC=ForestDnsZones,DC=srv,DC=SLD,DC=net
   DC=DomainDnsZones,DC=srv,DC=SLD,DC=net

These three requests are denied by the AD as they are not permitted
without a successful prior bind.
Dovecot then fails the auth process.

Is there a way to stop Dovecot from using the referals? Openldap seems
to have an option to disable referals, but Dovecot does not allow that
option in its LDAP config, and having the option set in the global
ldap.conf doesn't seem to help any, either. Is there possibly a way to
disable the referal information on the AD side?

Thanks, Garry

-- 
PGP Fingerprint: A79F A33F 5B13 BEB7 A51D 274F F99C 3AE2 4BCB 7015

Dynamic host with password plugin

[Jorge Bastos]

Howdy,

I’m making my multi-server instalation ready, but I’m facing just one small 
issue, that is with password plugin.

So, in config.inc.php of it I have:

config['password_db_dsn'] = 'mysql://webmail:bdkddz@192.168.69.222/postfix';

but, as I’m using in roundcube’s config.inc.php “dynamic” host:

$config['default_host'] = 'mail.%s';

Can I have in the password plugin config.inc.php the same variable?
(I can use same user/password/db on both servers for password change)

Thanks in advanced,

Re: Dovecot and Letsencrypt certs

[Robert Wolf]

On Wed, 13 Sep 2017, Luigi Rosa wrote:

> Robert Wolf wrote on 13/09/2017 10:26:
> 
> > are you sure? What is the refresh time? Instantly or with some delay? Have
> > you
> > tested what happens if I install new key, but I delay installing correct
> > certificate? Does postfix keep the old key+cert or stop using any cert
> > because
> > the new key is not correct for the current(old) certificate?
> > 
> > On my postfix 2.9.6 on debian wheezy 7 and postfix 2.11.3 on debian jessie 8
> > I
> > have to reload postfix. Postfix can use the same key+cert even if I deleted
> > these files.
> 
> Two days ago Viktor Dukhovni wrote on Postfix ML:
> 
> /*
> If you run certbot often enough to renew well in advance of expiration,
> reloads of Postfix are unnecessary, and just needlessly interrupt orderly
> processing of email by the queue manager.  Usually the new certificate will
> be automatically in use within "$max_idle * $max_use" seconds, and typically
> sooner, because processes either idle out quickly or reach the re-use limit
> quickly, handling $max_use connections that are exactly $max_idle apart is
> rather unlikely  By default that's 1 seconds or just under 3 hours.
> */


Hi Luigi,

you are right! The smtpd process really start using new certificate+key after 
this timeout (tested with max_use=1). OK, I thought it works similar as rsync 
daemon: the config file is read on new connection, because it starts new 
process. Similarly, the postfix master process starts the smtpd processes and 
they read config and cert+key again. It's clear now.

Still, I prefer to do reload if required and not wait until some timeout 
expires. And e.g. getssl client can check, if the certificate was correctly 
installed. And for this check it needs to run "reload".

And I prefer reload cert+key manually instead of automatically to be sure, WHEN 
it will be done.

So I am ok with dovecot to load cert+key on start and reload:-)


Regards,

Robert.

Re: Dovecot and Letsencrypt certs

[Luigi Rosa]

Robert Wolf wrote on 13/09/2017 10:26:


are you sure? What is the refresh time? Instantly or with some delay? Have you
tested what happens if I install new key, but I delay installing correct
certificate? Does postfix keep the old key+cert or stop using any cert because
the new key is not correct for the current(old) certificate?

On my postfix 2.9.6 on debian wheezy 7 and postfix 2.11.3 on debian jessie 8 I
have to reload postfix. Postfix can use the same key+cert even if I deleted
these files.


Two days ago Viktor Dukhovni wrote on Postfix ML:

/*
If you run certbot often enough to renew well in advance of expiration,
reloads of Postfix are unnecessary, and just needlessly interrupt orderly
processing of email by the queue manager.  Usually the new certificate will
be automatically in use within "$max_idle * $max_use" seconds, and typically
sooner, because processes either idle out quickly or reach the re-use limit
quickly, handling $max_use connections that are exactly $max_idle apart is
rather unlikely  By default that's 1 seconds or just under 3 hours.
*/




--


Ciao,
luigi

/
+--[Luigi Rosa]--
\

Statistics: The only science that enables different experts using the same
figures to draw different conclusions.
--Evan Esar

Re: Dovecot and Letsencrypt certs

[Robert Wolf]

On Tue, 12 Sep 2017, Daniel Miller wrote:

> And remove that "postfix reload" command - Postfix doesn't require explicit
> reloading. It'll pickup the changed cert automagically.
> 
> Daniel


Hoi Daniel,

are you sure? What is the refresh time? Instantly or with some delay? Have you 
tested what happens if I install new key, but I delay installing correct 
certificate? Does postfix keep the old key+cert or stop using any cert because 
the new key is not correct for the current(old) certificate?

On my postfix 2.9.6 on debian wheezy 7 and postfix 2.11.3 on debian jessie 8 I 
have to reload postfix. Postfix can use the same key+cert even if I deleted 
these files.


Reagrds,

Robert.