On Thursday 10 January 2008 05:24:01 Timo Sirainen wrote:

On Mon, 2008-01-07 at 21:50 +0100, Daniel wrote:

...

Recently I've experienced problems with dovecot. Dovecot died silently, what means is that there are no core files, nor any indication in the log files, just the "kevent(): Invalid argument" messages.

Any of them begin with "Fatal: "? Why is it giving kevent() errors anyway? Those shouldn't happen. Yes, this is all I get in the error log, and then dovecot dies silently. It won't produce a core file, or any indication of dying in the log file. Btw, I'm using OpenBSD 4.2, and kqueue.

...

deliver(leva): Can't connect to auth server at /var/run/dovecot/auth-master: Connection refused postfix/pipe[8582]: 8A1C6F261: to=<leva@domain.hu>, orig_to=<id>, relay=dovecot-lda, delay=1.7, delays=1.1/0/0/0 .68, dsn=2.0.0, status=sent (delivered via dovecot-lda service) postfix/qmgr[29441]: 8A1C6F261: removed

See? Postfix removed it from the queue, so basically all bets are off, and everything depends on deliver, but it just dropped the message. Is there anything that can be done regarding this issue?

Are you using some pre-v1.0.0 release? With v1.0.10 it seems to work correctly:

I'm updating dovecot with hg from HEAD.

% echo foo|./deliver -d user

deliver(user): Jan 10 06:20:47 Error: Can't connect to auth server at /usr/local/var/run/dovecot/auth-master: No such file or directory

Maybe my auth-master file remains there, but deliver couldn't connect to it, because dovecot has died. I guess the socket stayed there because dovecot couldn't clean up after itself in this case. Am I wrong (just guessing leastways...)?

% echo $? 75 % grep 75 /usr/include/sysexits.h #define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */

On Saturday 12 January 2008 09:54:03 Timo Sirainen wrote:

On Thu, 2008-01-10 at 18:53 +0100, Daniel wrote:

...

...

...

deliver(leva): Can't connect to auth server at /var/run/dovecot/auth-master: Connection refused postfix/pipe[8582]: 8A1C6F261: to=<leva@domain.hu>, orig_to=<id>, relay=dovecot-lda, delay=1.7, delays=1.1/0/0/0 .68, dsn=2.0.0, status=sent (delivered via dovecot-lda service) postfix/qmgr[29441]: 8A1C6F261: removed

I don't know why this would happen though. How are you executing deliver? I think the problem is with Postfix configuration or at least outside deliver. Currently, I'm executing deliver from a wrapper script:

master.cf:

dovecot-lda unix [...] argv=[...]/dovecot-lda_wrapper.pl ${recipient}

That script finds out the username which must be passed to deliver's -d option, because dovecot's user names are not the same as the recipient email addresses of the user's, so I can not just execute deliver directly with the -d ${recipient} option. This hack prevented deliver's exit code to get recognized by postfix.

...

Maybe my auth-master file remains there, but deliver couldn't connect to it, because dovecot has died. I guess the socket stayed there because dovecot couldn't clean up after itself in this case. Am I wrong (just guessing leastways...)?

I tested that in that situation deliver also returns temporary failure.

Daniel

On Saturday 12 January 2008 21:50:48 Asheesh Laroia wrote:

On Sat, 12 Jan 2008, Daniel wrote:

...

Currently, I'm executing deliver from a wrapper script:

master.cf:

dovecot-lda unix [...] argv=[...]/dovecot-lda_wrapper.pl ${recipient}

That script finds out the username which must be passed to deliver's -d option, because dovecot's user names are not the same as the recipient email addresses of the user's, so I can not just execute deliver directly with the -d ${recipient} option. This hack prevented deliver's exit code to get recognized by postfix.

Can you fix your dovecot-lda_wrapper.pl to either "exec" deliver, so that when it exits your process exits with the same number, or to do the Perl equivalent of "exit $?" - that is, exit the wrapper process with the exit code of the Dovecot LDA? Yes, I've been experimenting with the latter for a few hours now, and it is currently being tested.

Thanks!

Daniel

On 1/12/2008, Daniel (leva@az.isten.hu) wrote:

That script finds out the username which must be passed to deliver's -d option, because dovecot's user names are not the same as the recipient email addresses of the user's,

Curious - why is that? I'm just trying to think of a situation where the username and recipient would be different...

--

Best regards,

Charles

Eg. when a customer says: "Hey, I want my username to be "foo", and my email to be "bar@domain.com". :)

I encourage that on my servers. It's just one more layer of defense against password guessing zombies; beats me if it makes any difference.
I don't want to give them the userid for free just because they saw the email address on some spam list.