Re: [Dovecot] Moving Maildir files from multiple Dovecot installs

[Dean Manners]

Craig,
Yes rsyncing the Maildirs/ will work - be sure to get your recursion
options right though.  Personally I prefer to exempt the dovecot* files from
the rsync, and let them be recreated fresh on the new installation.

Regards
__ 
Dean Manners
 
> My question is how to transfer the maildir files from the 
> real users Maildirs to the created virtual users.  When 
> creating a mail user PostfixAdmin will create the maildir 
> directory.  Once this is created can I simply rsync the 
> complete old directory including the dovecot files to the new 
> mailbox? 
> 
> Sorry for the newbie question.
> 
> Many Thanks

[Dovecot] Moving Maildir files from multiple Dovecot installs

[craig carriere]

I currently have Dovecot running on a SuSE SLES 10 mail server with postfix as 
the MTA and a number of real linux users.  I have postfix delivering to Maildir 
records.  We are going to convert to a virtual user/domain system with 
PostfixAdmin.  I have checked out all of our settings and they appear to work 
well except for a problem with authenticating against mySQL using MD5-Crypt; 
plaintext works well however.

My question is how to transfer the maildir files from the real users Maildirs 
to the created virtual users.  When creating a mail user PostfixAdmin will 
create the maildir directory.  Once this is created can I simply rsync the 
complete old directory including the dovecot files to the new mailbox? 

Sorry for the newbie question.

Many Thanks

   
-
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.

[Dovecot] LDA sieve plugin [patch]

[Uldis Pakuls]

Hi all.

I spent some time testing Dovecot's LDA sieve plugin and found problem
with "notify" method.
In fact it always returns "generic sieve error"... and thus produces
bounce messages like this:
-

Your message was automatically rejected by Dovecot Mail Delivery Agent.

The following reason was given:
Unknown error

Deliver logs error: "generic sieve error", but otherwise server reports 
"notify" method as supported.


The problem is: original code was taken from curys sieve and requires 
"notifyd", as sieve runs 'chrooted'
and can't access external binaries like "sendmail". communications with notifyd 
is done via socket. 

Thus I wrote pacth, which ads "notify" functionality to dovecot's sieve plugin, 
at less "notify:mailto" method.

cyrus originally contains null, log and zephyr methods.
null and log is useless with dovecot, zephur is cyrus specific...

RFC docs says there is 3 available methods SMS, XMPP and MAILTO:
--
method can be an SMS URI [SMS-URI 
] 
containing a phone number, or an 
XMPP [XMPP 
] URI 
containing an XMPP identifier [XMPP-URI 
] 
The supported URI values will be site-specific, but support for the 
[MailTo ] 
method is REQUIRED in order to insure interoperability. If 
a URI schema is specified that the implementation does not support, 
the notification MUST cause an error condition. Sieve scripts can 
check the supported methods using the "valid_notify_method" test to 
be sure that they only use supported ones, to avoid such error 
conditions.
--
as SMS-URI and XMPP methods are not included in cyrus sieve version, they are 
not available in dovecots plugin too.
[any ideas, sample code how to implement them?]

BUT... WARNING
All this will not work if you have "mail_chroot" setting enabled in 
dovecot.conf; chrooted process can't access required external binaries.
DOT USE THIS PLUGIN WITH "mail_chroot" SENTIG ENABLED!

Actualy it is not sieve plugin problem only - its LDA problem... it can't send 
bonce messages, do forwards etc.


Question to Timo: 
Do You have ideas how to fix it? My be disable chroting for LDA at all? or do 
it "cyrus way" - move all calls to external binaries to sepreate, non chrooted 
process?
For delivery agent it is requred to be able send bounces and notifications... 
do forwards.

Uldis 





--- sieve-org/dovecot-sieve/src/sieve-cmu.c	2006-10-10 22:46:23.0 +0200
+++ sieve-new/dovecot-sieve/src/sieve-cmu.c	2007-04-13 01:19:16.0 +0200
@@ -18,6 +18,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -258,24 +259,50 @@
 			void *mc __attr_unused__,
 			const char **errmsg __attr_unused__)
 {
-#if 0
-const char *notifier = config_getstring(IMAPOPT_SIEVENOTIFIER);
+sieve_notify_context_t *nc = (sieve_notify_context_t *) ac;
+sieve_msgdata_t *m = mc;
 
-if (notifier) {
-	sieve_notify_context_t *nc = (sieve_notify_context_t *) ac;
-	script_data_t *sd = (script_data_t *) script_context;
-	int nopt = 0;
-
-	/* count options */
-	while (nc->options[nopt]) nopt++;
-
-	/* "default" is a magic value that implies the default */
-	notify(!strcmp("default",nc->method) ? notifier : nc->method,
-	   "SIEVE", nc->priority, sd->username, NULL,
-	   nopt, nc->options, nc->message);
+int nopt = 0;
+FILE *f;
+struct smtp_client *smtp_client;
+const char *outmsgid;
+
+/* count options */
+while (nc->options[nopt]) nopt++; {
+
+/* default is "mailto" as only one... */
+	if (strcasecmp(nc->method, "default")) nc->method = "mailto";
+if (strcasecmp(nc->method, "mailto")) { 
+	*errmsg = "Unknown [unimplemented] notify method";
+	return SIEVE_FAIL;
+	}
+
+	smtp_client = smtp_client_open(nc->options[0], NULL, &f);
+	outmsgid = deliver_get_new_message_id();
+	fprintf(f, "Message-ID: %s\r\n", outmsgid);
+	fprintf(f, "Date: %s\r\n", message_date_create(ioloop_time));
+	fprintf(f, "X-Sieve: %s\r\n", SIEVE_VERSION);
+	fprintf(f, "X-Priority: %s\r\n", nc->priority);
+	fprintf(f, "From: Postmaster <%s>\r\n", getenv("POSTMASTER_ADDRESS"));
+	fprintf(f, "To: <%s>\r\n", nc->options[0]);
+	fprintf(f, "Subject: [SIEVE] New mail notification\r\n");
+	fprintf(f, "MIME-Version: 1.0\r\n");
+	fprintf(f, "Content-Type: text/plain; charset=utf-8\r\n");
+	fprintf(f, "Content-Transfer-Encoding: 8bit\r\n");
+	fprintf(f, "\r\n");
+	fprintf(f, "%s\r\n", nc->message);
+	fprintf(f, "\r\n");
+	i_info("msgid=%s: sent notification to <%s>", 
+	   m->id == NULL ? "" : str_sanitize(m->id, 80),
+	   str_sanitize(nc->options[0], 80));
+	if (smtp_client_close(smtp_client) == 0) {
+	return SIEVE_OK;
+	} else {
+	*errmsg = "Error sending notify mail";
+	return SIEVE_FAIL;
+	}
 }
-#endif

Re: [Dovecot] 1.0.rc32 released

[Matthias Andree]

Marc Perkel schrieb:
> Remember even if you don't get everything right by tomorrow there's
> always version 1.01. There will always be bugs and new features to add.

I do hope Timo will leave bugs and features to the HEAD branch and save
the fixes for 1.0.X :-) [1]

Anyways, to Timo - good luck with the release - if time doesn't suffice,
call it "Friday 23:59 UTC" which buys you three extra hours in Eastern
European Daylight Savings Time. =:-)

[1] Ok, call me German for counting peas... I don't mind as that's a
factual description. 8-)

Re: [Dovecot] 1.0.rc32 released

[Marc Perkel]

Remember even if you don't get everything right by tomorrow there's 
always version 1.01. There will always be bugs and new features to add.

Re: [Dovecot] 1.0.rc32 released

[Ben Beuchler]

The LDAP_DEPRECATED define should have fixed these. Maybe your ldap.h
doesn't have the deprecated functions at all for some reason? Or did I
somehow mess up applying the deprecated-patch. :)


rc32 builds cleanly for me (only a few minor warnings) and seems to be
running well.

Thanks!

-Ben

Re: [Dovecot] 1.0.rc32 released

[Timo Sirainen]

On Thu, 2007-04-12 at 18:58 +0100, Chris Wakelin wrote:
> Well, it builds OK for me on Solaris 8 32-bit SPARC with OpenLDAP 2.3,
> with less complaints from gcc (3.3.2), just:-
> 
> mail-index.c: In function `mail_index_parse_extensions':
> mail-index.c:343: warning: comparison between signed and unsigned
> mail-index.c: In function `mail_index_map_clone':
> mail-index.c:1294: warning: comparison between signed and unsigned
> idxview.c: In function `dump_hdr':
> idxview.c:89: warning: comparison between signed and unsigned
> idxview.c: In function `dump_cache_hdr':
> idxview.c:179: warning: comparison between signed and unsigned
> idxview.c:194: warning: comparison between signed and unsigned
> idxview.c: In function `dump_cache':
> idxview.c:243: warning: comparison between signed and unsigned
> idxview.c: In function `dump_record':
> idxview.c:345: warning: comparison between signed and unsigned

These should all go away with a newer gcc.

> whereas before I had:-
> db-ldap.c: In function `db_ldap_search':
> db-ldap.c:201: warning: implicit declaration of function `ldap_search'

The LDAP_DEPRECATED define should have fixed these. Maybe your ldap.h
doesn't have the deprecated functions at all for some reason? Or did I
somehow mess up applying the deprecated-patch. :)

I'd anyway try fixing these warnings before trying to run the code. I
guess they should work with 32bit systems without crashing, but I
wouldn't bet on it.


signature.asc
Description: This is a digitally signed message part

Re: [Dovecot] 1.0.rc32 released

[Chris Wakelin]

Well, it builds OK for me on Solaris 8 32-bit SPARC with OpenLDAP 2.3,
with less complaints from gcc (3.3.2), just:-

mail-index.c: In function `mail_index_parse_extensions':
mail-index.c:343: warning: comparison between signed and unsigned
mail-index.c: In function `mail_index_map_clone':
mail-index.c:1294: warning: comparison between signed and unsigned
idxview.c: In function `dump_hdr':
idxview.c:89: warning: comparison between signed and unsigned
idxview.c: In function `dump_cache_hdr':
idxview.c:179: warning: comparison between signed and unsigned
idxview.c:194: warning: comparison between signed and unsigned
idxview.c: In function `dump_cache':
idxview.c:243: warning: comparison between signed and unsigned
idxview.c: In function `dump_record':
idxview.c:345: warning: comparison between signed and unsigned

whereas before I had:-
db-ldap.c: In function `db_ldap_search':
db-ldap.c:201: warning: implicit declaration of function `ldap_search'
db-ldap.c: In function `db_ldap_bind_callback':
db-ldap.c:425: warning: implicit declaration of function `ldap_result2error'
db-ldap.c: In function `db_ldap_bind':
db-ldap.c:443: warning: implicit declaration of function `ldap_bind'
db-ldap.c: In function `db_ldap_connect':
db-ldap.c:494: warning: implicit declaration of function `ldap_init'
db-ldap.c:494: warning: assignment makes pointer from integer without a cast
db-ldap.c: In function `ldap_conn_close':
db-ldap.c:599: warning: implicit declaration of function `ldap_unbind'
passdb-ldap.c: In function `ldap_query_save_attr':
passdb-ldap.c:84: warning: implicit declaration of function
`ldap_get_values'
passdb-ldap.c:84: warning: assignment makes pointer from integer without
a cast
passdb-ldap.c:103: warning: implicit declaration of function
`ldap_value_free'
passdb-ldap.c: In function `handle_request_get_entry':
passdb-ldap.c:155: warning: implicit declaration of function
`ldap_result2error'
passdb-ldap.c: In function `authbind_start':
passdb-ldap.c:268: warning: implicit declaration of function `ldap_bind'
userdb-ldap.c: In function `ldap_query_get_result':
userdb-ldap.c:84: warning: implicit declaration of function
`ldap_get_values'
userdb-ldap.c:84: warning: assignment makes pointer from integer without
a cast
userdb-ldap.c:104: warning: implicit declaration of function
`ldap_value_free'
userdb-ldap.c: In function `handle_request':
userdb-ldap.c:146: warning: implicit declaration of function
`ldap_result2error'

as well.

Hopefully I'll manage to try some direct LDAP auth before tomorrow
(we're using pam_ldap instead at the moment). I'll let you know if there
are any issues.

Best Wishes,
Chris

Timo Sirainen wrote:
> One thing that I'm a bit concerned about is the addition of #define
> LDAP_DEPRECATED. I know it fixes crashes with OpenLDAP 2.3 + 64bit
> systems, but I hope it doesn't break compiling with some old versions or
> non-OpenLDAP libraries..

-- 
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
Christopher Wakelin,   [EMAIL PROTECTED]
IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 8439
Whiteknights, Reading, RG6 2AF, UK  Fax: +44 (0)118 975 3094

[Dovecot] 1.0.rc32 released

[Timo Sirainen]

http://dovecot.org/releases/dovecot-1.0.rc32.tar.gz
http://dovecot.org/releases/dovecot-1.0.rc32.tar.gz.sig

Pretty late for changes if v1.0 is supposed to come out tomorrow, but I
can't really leave these LDAP bugs unfixed. They shouldn't anyway break
anything, so here's one more day for you people to find out about any
bugs.

One thing that I'm a bit concerned about is the addition of #define
LDAP_DEPRECATED. I know it fixes crashes with OpenLDAP 2.3 + 64bit
systems, but I hope it doesn't break compiling with some old versions or
non-OpenLDAP libraries..

- LDAP, auth_bind=no: Don't crash if doing non-plaintext ldap passdb
  lookup for unknown user. This also broke deliver when userdb static
  was used.
- LDAP, auth_bind=yes and userdb ldap: We didn't wait until bind was
  finished before sending the userdb request, which could have caused
  problems.
- LDAP: Don't break when compiling with OpenLDAP v2.3 library
- Convert plugin: Don't create "maildirfolder" file to Maildir root.



signature.asc
Description: This is a digitally signed message part

Re: [Dovecot] convert plugin created maildirfolder file in root maildir directory

[Timo Sirainen]

On Thu, 2007-04-12 at 12:33 -0400, Justin McAleer wrote:
> I've noticed that if a user's maildir gets created by deliver or 
> pop/imap without the convert plugin running, the maildir structure is 
> fine (no maildirfolder file). But, if a user gets converted, there is a 
> maildirfolder file in the user's base maildir directory. As far as I can 
> tell, that doesn't cause any problems, but I just wanted to mention it. 
> I've looked at the code for a while but didn't find why it behaves 
> differently.

Dovecot doesn't care about maildirfolder file, but if you use a MDA that
updates Maildir++ quota you could have problems.

Fixed: http://dovecot.org/list/dovecot-cvs/2007-April/008659.html


signature.asc
Description: This is a digitally signed message part

Re: [Dovecot] Connection refused with auth-master afterupgradingtoDovecot 1.0 rc 28

[Jason Warner]

Thank you Timo. You have been extremely helpful in this.

> -Original Message-
> From: Timo Sirainen [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 12, 2007 10:39 AM
> To: Jason Warner
> Cc: 'Jason Warner'; 'Dovecot Mailing List'
> Subject: Re: [Dovecot] Connection refused with auth-master
> afterupgradingtoDovecot 1.0 rc 28
> 
> On Tue, 2007-04-10 at 13:12 -0600, Jason Warner wrote:
> > > Anyway I should be able to figure out the assert by looking at the
> > > code too. Just a bit more difficult, since a couple of minutes wasn't
> > > enough. :)
> 
> This should fix it:
> http://dovecot.org/list/dovecot-cvs/2007-April/008653.html

Re: [Dovecot] Connection refused with auth-master afterupgradingto Dovecot 1.0 rc 28

[Timo Sirainen]

On Tue, 2007-04-10 at 13:12 -0600, Jason Warner wrote:
> > Anyway I should be able to figure out the assert by looking at the
> > code too. Just a bit more difficult, since a couple of minutes wasn't
> > enough. :)

This should fix it:
http://dovecot.org/list/dovecot-cvs/2007-April/008653.html


signature.asc
Description: This is a digitally signed message part

Re: [Dovecot] Dovecot deliver agent - dovecot.conf permissions

[Timo Sirainen]

On Wed, 2007-04-11 at 11:43 +0200, Emiliano Gabrielli (aka AlberT)
wrote:
> 
> yea, but I have the same issue with log files ... and I don't like to
> make the 
> logs readable by anyone not being root ... It's impossible to run the
> deliver 
> in postfix without changing the logs owner ??? 

If you really want to avoid that, it's also possible to run deliver as
setuid-root. See http://wiki.dovecot.org/LDA

Or you could use syslog and just make /dev/log writable to everyone.



signature.asc
Description: This is a digitally signed message part

[Dovecot] convert plugin created maildirfolder file in root maildir directory

[Justin McAleer]

I've noticed that if a user's maildir gets created by deliver or 
pop/imap without the convert plugin running, the maildir structure is 
fine (no maildirfolder file). But, if a user gets converted, there is a 
maildirfolder file in the user's base maildir directory. As far as I can 
tell, that doesn't cause any problems, but I just wanted to mention it. 
I've looked at the code for a while but didn't find why it behaves 
differently.

Re: [Dovecot] Comment from OpenLDAP developer regarding "deferring operations"

[Ben Beuchler]

On 4/12/07, Timo Sirainen <[EMAIL PROTECTED]> wrote:

On Wed, 2007-04-11 at 19:50 -0500, Ben Beuchler wrote:
> I'd note that if your client is performing search + bind on the same
> connection in an asynchronous manner, then the server behavior as per
> RFC4511 is undefined, since a server is not supposed to be willing to
> handle operations intermixed with binds until a bind is concluded.  That
> is, any operation can be multiplexed on a single LDAP connection
> __except__ binds, which must be serialized.

That's how I thought it was working. But I think I found a bug in there.
See if the attached patch fixes it?


It does!  Not a single "deferring operation" entry in nearly an hour!

Now to wait and see if this change, Roy's patch, and linking against
the new libldap_r can combine to eliminate my intermittent (and
frustratingly non-reproducible) auth freezes.

-Ben

Re: [Dovecot] Dovecot Assertion on mail server with POP3 and LDAP authentication

[Tim Alberts]

Timo Sirainen wrote:

On 10.4.2007, at 20.31, Tim Alberts wrote:

Apr  4 08:44:38 msi2 dovecot: auth(default): dovecot-auth: 
../../../libraries/liblber/io.c:491: ber_get_next: Assertion 
`ber->ber_buf == ((void *)0)' failed.
Apr  4 08:44:38 msi2 dovecot: auth(default): 
pam(secretuser,192.168.0.200): Child process died

..

 passdb:
   driver: pam
 userdb:
   driver: passwd


So you're using pam_ldap and nss_ldap. See 
http://wiki.dovecot.org/AuthDatabase/Passwd


So I'd suggest upgrading.



Thank you for the quick response.  It doesn't look like the problem 
I'm having though?  I don't have problems with people getting other 
peoples email.  I have problems with the Assertion errors that I 
mentioned.


No, but it could very well be caused by the same problem.




Just to close off this threadThis seems to have fixed the problem.  
I upgraded to a newer version and that alone made a huge difference.  
However, I didn't make the configuration changes I was supposed to at 
that time.  The following day, I checked the server logs and saw the 
problem happen a couple times within a second and that was it.  
Significantly less, but it prompted me to read the dovecot website again 
and make the recommended configuration changes.


Running for a couple days now, no problems and positive reports from the 
clients.  Thank you for the resolution and best wishes to everyone.

[Dovecot] auth-login crash with cram-md5 (plain works) on unknown user

[Charlie Allom]

Hello Timo and others..

14:09 mail:~# dovecot --version
1.0.rc31

Install prefix .. : 
/usr/local  
File offsets  : 64bit
I/O loop method . : poll
File change notification method . : inotify
Building with SSL support ... : yes (OpenSSL)
Building with IPv6 support .. : yes
Building with pop3 server ... : yes
Building with mail delivery agent  .. : yes
Building with GSSAPI support  : no
Building with user database modules . : static prefetch passwd 
passwd-file checkpassword ldap (modules)
Building with password lookup modules : passwd passwd-file shadow 
checkpassword ldap (modules)
Building with SQL drivers :

when logging in as an *unknown* user - with CRAM-MD5 and an LDAP 
pass/userdb i get this crash of the auth process:

==> /var/log/dovecot.log <==
dovecot: 2007-04-12 13:50:14 Error: auth(default): file 
auth-request.c: line 474
 (auth_request_lookup_credentials_callback): assertion failed: 
(request->state =
= AUTH_REQUEST_STATE_PASSDB)
dovecot: 2007-04-12 13:50:14 Error: auth(default): Raw backtrace: 
dovecot-auth [0x80665a1] -> dovecot-auth [0x80664bc] -> dovecot-auth 
[0x805429e] -> dovecot-auth [0x805d7fd] -> dovecot-auth [0x805dbc4] -> 
dovecot-auth [0x8057f3b] -> dovecot-auth(io_loop_handler_run+0x110) 
[0x8069730] -> dovecot-auth(io_loop_run+0x1c) [0x8068c8c] -> 
dovecot-auth(main+0x2fe) [0x805920e] -> 
/lib/libc.so.6(__libc_start_main+0xdc) [0xb7db58cc] -> dovecot-auth 
[0x804fb51]
dovecot: 2007-04-12 13:50:14 Error: child 7163 (auth) killed with 
signal 6

logging in via plain works nicely:

==> /var/log/dovecot.info <==
dovecot: 2007-04-12 14:08:12 Info: Dovecot v1.0.rc31 starting up
dovecot: 2007-04-12 14:08:27 Info: auth(default): 
ldap(yeled,19.8.5.23): unknown user

ldap entry of unknown user:
dn: uid=yeled,ou=users,dc=playlouder,dc=com
uid: yeled
sn: yeled
cn: Charles Allom
userPassword:: ddd=
objectClass: inetOrgPerson
objectClass: CourierMailAlias
mail: [EMAIL PROTECTED]
maildrop: [EMAIL PROTECTED]

ldap entry of known user:
uid: luke
sn: luke
cn: Luke
userPassword:: ddd=
objectClass: inetOrgPerson
objectClass: mspUser
objectClass: CourierMailAccount
mail: [EMAIL PROTECTED]
homeDirectory: /home/l/luke
gidNumber: 5000
uidNumber: 5000

and my ldap config:
hosts = beta.playlouder.com
dn = cn=admin,dc=playlouder,dc=com
dnpass = ddd
auth_bind = no
ldap_version = 3
base = ou=users,dc=playlouder,dc=com
scope = subtree
user_attrs = homeDirectory=home,uidNumber=uid,gidNumber=gid
user_filter = (&(objectClass=CourierMailAccount)(uid=%n))
pass_attrs = uid=user,userPassword=password
pass_filter = (&(objectClass=CourierMailAccount)(uid=%n))
default_pass_scheme = PLAIN
user_global_uid = 5000
user_global_gid = 5000

as you can see I'm setting CourierMailAlias on users with no dovecot 
access, and CourierMailAccount on users with imap/pop logins. the 
passwords in openldap are plain (b64)

i have included the strace output...

13:49:54.112641 gettimeofday({1176385794, 112728}, {0, 0}) = 0
13:49:54.112757 gettimeofday({1176385794, 112771}, NULL) = 0
13:49:54.112792 poll([{fd=5, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=7, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=0, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=3, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=15, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=8, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=17, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=10, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=12, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=13, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=14, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=9, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}], 12, 579) = 0
13:49:54.691245 gettimeofday({1176385794, 691271}, {0, 0}) = 0
13:49:54.691295 gettimeofday({1176385794, 691307}, NULL) = 0
13:49:54.691328 poll([{fd=5, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=7, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=0, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=3, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=15, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=8, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=17, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=10, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=12, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=13, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=14, 
events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, {fd=9, 
events=POLLIN|PO

Re: [Dovecot] Comment from OpenLDAP developer regarding "deferring operations"

[Ben Beuchler]

I'll apply the patch later this morning and and let you know what I see.

For what it's worth, last night I started dumping traffic between
dovecot and openldap.  The pattern I see most consistently was this:

-> bind request (anonymous)
-> search request
<- bind response
<- search result

As I understand it, the search request being sent before the result of
the bind request is received could trigger the deferrals.

Thanks!

-Ben

On 4/12/07, Timo Sirainen <[EMAIL PROTECTED]> wrote:

On Wed, 2007-04-11 at 19:50 -0500, Ben Beuchler wrote:
> I'd note that if your client is performing search + bind on the same
> connection in an asynchronous manner, then the server behavior as per
> RFC4511 is undefined, since a server is not supposed to be willing to
> handle operations intermixed with binds until a bind is concluded.  That
> is, any operation can be multiplexed on a single LDAP connection
> __except__ binds, which must be serialized.

That's how I thought it was working. But I think I found a bug in there.
See if the attached patch fixes it?

[Dovecot] [PATCH] Compile cleaning against OpenLDAP 2.3.x

[Roy Marples]

Hi List

Looks like OpenLDAP 2.3 doesn't define LDAP_DEPRECATED [1] anymore which
causes a few warnings in Gentoo [2].

Attached is a patch that re-defines this so that dovecot can continue
using simple functions like ldap_bind().

Thanks

Roy

[1]
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00487.html

[2] http://bugs.gentoo.org/show_bug.cgi?id=162437diff -ur /tmp/dovecot-1.0.rc29/src/auth/db-ldap.h dovecot-1.0.rc29/src/auth/db-ldap.h
--- /tmp/dovecot-1.0.rc29/src/auth/db-ldap.h	2007-01-19 15:15:13.0 +
+++ dovecot-1.0.rc29/src/auth/db-ldap.h	2007-04-12 09:29:06.0 +0100
@@ -1,6 +1,10 @@
 #ifndef __DB_LDAP_H
 #define __DB_LDAP_H
 
+/* Functions like ldap_bind have been deprecated in openldap 2.3
+ * This define enables them until the code here can be refactored */
+#define LDAP_DEPRECATED 1
+
 #include 
 
 struct auth_request;

Re: [Dovecot] Comment from OpenLDAP developer regarding "deferring operations"

[Timo Sirainen]

On Wed, 2007-04-11 at 19:50 -0500, Ben Beuchler wrote:
> I'd note that if your client is performing search + bind on the same
> connection in an asynchronous manner, then the server behavior as per
> RFC4511 is undefined, since a server is not supposed to be willing to
> handle operations intermixed with binds until a bind is concluded.  That
> is, any operation can be multiplexed on a single LDAP connection
> __except__ binds, which must be serialized.

That's how I thought it was working. But I think I found a bug in there.
See if the attached patch fixes it?

Index: src/auth/db-ldap.c
===
RCS file: /var/lib/cvs/dovecot/src/auth/db-ldap.c,v
retrieving revision 1.41.2.18
diff -u -r1.41.2.18 db-ldap.c
--- src/auth/db-ldap.c	19 Jan 2007 15:27:42 -	1.41.2.18
+++ src/auth/db-ldap.c	12 Apr 2007 08:00:32 -
@@ -196,6 +196,8 @@
 request->callback(conn, request, NULL);
 return;
 			}
+			db_ldap_add_delayed_request(conn, request);
+			return;
 		}
 
 		msgid = ldap_search(conn->ld, request->base, scope,


signature.asc
Description: This is a digitally signed message part