[Dovecot] need help with dovecot-lda
Hello all!
Some month ago I upgraded our dovecot installation from version 1.0.5 to version 2.1.7 without having any trouble. Postfix is delivering email directly per virtual transport to the maildirs and mailboxes of the users in /var/spool/vhosts/domains/....
Now I want to use dovecot-lda and created a new entry in the master.cf of postfix.
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/dovecot-lda -f ${sender} -d ${recipient}
It is not clear to me, how the dovecot-lda is started bei dovecot and you it finds the socket dovecot postfix created.
The dovecot.conf looks like this;
# 2.1.7: /etc/dovecot/dovecot.conf # OS: Linux 2.6.22.5-31-bigsmp i686 openSUSE 10.3 (i586) ext3
auth_verbose = yes disable_plaintext_auth = no log_path = /var/log/dovecot1
mail_location = mbox:/var/spool/vhosts/%d/dovecotprivate/%n:INBOX=/var/spool/vhosts/%d/%n
!include /etc/dovecot/conf.d/*.conf
passdb { args = /etc/dovecot/passwd driver = passwd-file } userdb { args = /etc/dovecot/passwd driver = passwd-file }
ssl_cert = < /etc/dovecot/ssl/hostcert.pem ssl_key = < /etc/dovecot/ssl/hostkey.pem #verbose_ssl = yes
plugin { quota = maildir:User quota quota_rule = *:storage=500MB # 10% of 1GB = 100MB quota_rule2 = Trash:storage=+10%% # 20% of 1GB = 200MB # quota_rule3 = Spam:storage=+20%%
autocreate = Trash
autocreate2 = Drafts
autocreate3 = Sent
autosubscribe = Trash
autosubscribe2 = Drafts
autosubscribe3 = Sent}
I set soft_bounce = yes in main.cf of postfix and delivery of mail fails with
Dec 14 16:13:34 delta postfix/virtual[14082]: BBC0F1B31294: to=xyz@anup.de, relay=virtual, delay=395, delays=395/0.01/0/0.13, dsn=4.1.1, status=SOFTBOUNCE (unknown user: "xyz@anup.de")
This is the relevant part of the main.cf:
dovecot_destination_recipient_limit = 1
virtual_mailbox_domains = anup.de bit-corner.de bitcorner.de baubetreuung-meyer.de saxelektro.de virtual_mailbox_base = /var/spool/vhosts #virtual_mailbox_maps = hash:/etc/postfix/vmailbox #virtual_minimum_uid = 100 #virtual_uid_maps = static:5000 #virtual_gid_maps = static:5000 virtual_mailbox_limit = 524288000 virtual_transport = dovecot
I don't get it right. As far as I understand postfix uses virtual_transport = dovecot and hands the mail over to the socket dovecot. But how does dovecot know where to look for the socket. I am missing somthing but don't know what.
Any help is appreciated!
Andreas
At 5PM +0100 on 14/12/12 Andreas Meyer wrote:
Some month ago I upgraded our dovecot installation from version 1.0.5 to version 2.1.7 without having any trouble. Postfix is delivering email directly per virtual transport to the maildirs and mailboxes of the users in /var/spool/vhosts/domains/....
Now I want to use dovecot-lda and created a new entry in the master.cf of postfix.
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/dovecot-lda -f ${sender} -d ${recipient}
It is not clear to me, how the dovecot-lda is started bei dovecot and you it finds the socket dovecot postfix created.
The process listening on that 'dovecot' pipe is a Postfix pipe(8) process. When a delivery request comes in from elsewhere in Postfix, it invokes /usr/libexec/dovecot/dovecot-lda as a new child process. This new lda process will contact the dovecot-auth service if it needs to, but is otherwise not connected to the running Dovecot server at all.
If you want Dovecot to listen for deliveries (which has some efficiency advantages), you want to use LMTP.
I set soft_bounce = yes in main.cf of postfix and delivery of mail fails with
Dec 14 16:13:34 delta postfix/virtual[14082]: BBC0F1B31294: to=xyz@anup.de, relay=virtual, delay=395, delays=395/0.01/0/0.13, dsn=4.1.1, status=SOFTBOUNCE (unknown user: "xyz@anup.de")
What happens if you run
echo "foo" | /usr/libexec/dovecot/dovecot-lda \
-f xyz@anup.de -d xyz@anup.dein the shell (as the vmail user)? Does it fail with exit code 67? This is EX_NOUSER, and is the standard way for LDAs to signal 'I don't know how to deliver to this user'. Either xyz@anup.de is not a valid address at that domain, or you haven't made the auth-userdb socket available to the vmail user. See http://wiki2.dovecot.org/LDA, under the section 'Virtual users'.
Ben
Hello!
Ben Morrow ben@morrow.me.uk wrote:
At 5PM +0100 on 14/12/12 Andreas Meyer wrote:
Some month ago I upgraded our dovecot installation from version 1.0.5 to version 2.1.7 without having any trouble. Postfix is delivering email directly per virtual transport to the maildirs and mailboxes of the users in /var/spool/vhosts/domains/....
Now I want to use dovecot-lda and created a new entry in the master.cf of postfix.
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/dovecot-lda -f ${sender} -d ${recipient}
It is not clear to me, how the dovecot-lda is started bei dovecot and you it finds the socket dovecot postfix created.
The process listening on that 'dovecot' pipe is a Postfix pipe(8) process. When a delivery request comes in from elsewhere in Postfix, it invokes /usr/libexec/dovecot/dovecot-lda as a new child process. This new lda process will contact the dovecot-auth service if it needs to, but is otherwise not connected to the running Dovecot server at all.
If you want Dovecot to listen for deliveries (which has some efficiency advantages), you want to use LMTP.
I set soft_bounce = yes in main.cf of postfix and delivery of mail fails with
Dec 14 16:13:34 delta postfix/virtual[14082]: BBC0F1B31294: to=xyz@anup.de, relay=virtual, delay=395, delays=395/0.01/0/0.13, dsn=4.1.1, status=SOFTBOUNCE (unknown user: "xyz@anup.de")
What happens if you run
echo "foo" | /usr/libexec/dovecot/dovecot-lda \ -f xyz@anup.de -d xyz@anup.dein the shell (as the vmail user)? Does it fail with exit code 67? This is EX_NOUSER, and is the standard way for LDAs to signal 'I don't know how to deliver to this user'. Either xyz@anup.de is not a valid address at that domain, or you haven't made the auth-userdb socket available to the vmail user. See http://wiki2.dovecot.org/LDA, under the section 'Virtual users'.
I did this in the shell:
delta:/ # su vmail delta:/ # whoami root delta:/ # echo "test" | /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de
and the mail was delivered to the mailbox without error. Maybe the vmail user is the problem? When I send an email from my desktop I get this in the mail.log: Dec 14 21:19:42 delta postfix/virtual[16185]: A6E511B3128A: to=anmeyer@anup.de, relay=virtual, delay=0.15, delays=0.08/0.01/0/0.06, dsn=4.1.1, status=SOFTBOUNCE (unknown user: "anmeyer@anup.de")
The line of the /etc/shadow for vmail looks like this: vmail::13940:0:99999:7:::
Why is root not switching to vmail? May vmail be the problem?
delta:/ # id vmail uid=110(vmail) gid=110(vmail) Gruppen=110(vmail)
Andreas
At 9PM +0100 on 14/12/12 Andreas Meyer wrote:
Ben Morrow ben@morrow.me.uk wrote:
At 5PM +0100 on 14/12/12 Andreas Meyer wrote:
Some month ago I upgraded our dovecot installation from version 1.0.5 to version 2.1.7 without having any trouble. Postfix is delivering email directly per virtual transport to the maildirs and mailboxes of the users in /var/spool/vhosts/domains/....
<snip> > I set soft_bounce = yes in main.cf of postfix and delivery of mail > fails with > > Dec 14 16:13:34 delta postfix/virtual[14082]: BBC0F1B31294: > to=<xyz@anup.de>, relay=virtual, delay=395, delays=395/0.01/0/0.13, > dsn=4.1.1, status=SOFTBOUNCE (unknown user: "xyz@anup.de")
What happens if you run
echo "foo" | /usr/libexec/dovecot/dovecot-lda \ -f xyz@anup.de -d xyz@anup.dein the shell (as the vmail user)? Does it fail with exit code 67? This is EX_NOUSER, and is the standard way for LDAs to signal 'I don't know how to deliver to this user'. Either xyz@anup.de is not a valid address at that domain, or you haven't made the auth-userdb socket available to the vmail user. See http://wiki2.dovecot.org/LDA, under the section 'Virtual users'.
I did this in the shell:
delta:/ # su vmail delta:/ # whoami root
So su didn't work. That's often the case with daemon users, because they often don't have a login shell. Read the manpage for your system's su to find out if you can override that, and how (I can't help you here, since your su is probably different from mine). You may have more luck with sudo, if you've got it installed.
delta:/ # echo "test" | /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de
and the mail was delivered to the mailbox without error. Maybe the vmail user is the problem?
That is delivered to 'anmayer@anup.de', which looks a lot more like a real address than 'xyz@anup.de'.
When I send an email from my desktop I get this in the mail.log: Dec 14 21:19:42 delta postfix/virtual[16185]: A6E511B3128A: to=anmeyer@anup.de, relay=virtual, delay=0.15, delays=0.08/0.01/0/0.06, dsn=4.1.1, status=SOFTBOUNCE (unknown user: "anmeyer@anup.de")
So it's likely the vmail user can't read the userdb; do you not get any logs from dovecot-lda? (You may not if Dovecot is using custom logs rather than syslog, and vmail doesn't have write access.)
The line of the /etc/shadow for vmail looks like this: vmail::13940:0:99999:7:::
How is that relevant? AFAIK the login shell lives in /etc/passwd on shadow-password systems.
At 11AM +0100 on 15/12/12 Andreas Meyer wrote:
# id vmail uid=5000(vmail) gid=5000(vmail) Gruppen=5000(vmail)
# su vmail echo "foo" | /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de an empty email with 0 B gets delivered to the maildir of anmeyer@anup.de
That command-line attempts to run 'echo "foo"' as the vmail user, and dovecot-lda as root (and I don't know if the arguments to su are correct; on my system they wouldn't be). You *really* need to learn how to use your operating system before you try anything relatively complicated like setting up a mail server.
in the shell (as the vmail user)? Does it fail with exit code 67? This is EX_NOUSER, and is the standard way for LDAs to signal 'I don't know how to deliver to this user'. Either xyz@anup.de is not a valid address at that domain, or you haven't made the auth-userdb socket available to the vmail user. See http://wiki2.dovecot.org/LDA, under the section 'Virtual users'.
I already added
service auth { unix_listener auth-userdb { mode = 0600 user = vmail # User running dovecot-lda group = vmail # Or alternatively mode 0660 + dovecot-lda user in this group
You're supposed to understand the comments and then remove them, not copy them blindly without reading them.
}}
to the dovecot.conf.
Well, that looks OK to me; but the only way to test it is to manually run dovecot-lda as vmail. Is there an auth-userdb socket in your dovecot sockets directory? Does it have the right permissions?
How does dovecot know there is a socket in /var/spool/postfix/private/dovecot? And how does dovecot-lda know to look there. Am I missunderstanding something?
Yes, you are misunderstanding something. It works (something) like this:
- A mail comes in to Postfix.
- Postfix decides this mail is local.
- Postfix sends the mail through /var/spool/postfix/private/dovecot
to a Postfix pipe(8) process on the other end.
- That pipe(8) process runs dovecot-lda, as the vmail user.
- dovecot-lda reads dovecot.conf.
- dovecot-lda contacts the Dovecot auth process using the
auth-userdb socket.
- If the user exists, it delivers the mail to their mailbox.No Dovecot process needs to know anything at all about the Postfix socket, it's just for internal communication between different bits of Postfix. Have you read the Postfix documentation?
I am lost. I don't if the mail is handed over to dovecot-lda and if so why it can't find the passwd-file.
If the mail was handed over to dovecot-lda, it ought to be logging *something*. Find out where those logs should go; if they aren't appearing, you need to fix that. Syslog is IMHO a better bet than custom log files.
Ben
Hello!
I already added
service auth { unix_listener auth-userdb { mode = 0600 user = vmail # User running dovecot-lda group = vmail # Or alternatively mode 0660 + dovecot-lda user in this group
You're supposed to understand the comments and then remove them, not copy them blindly without reading them.
That's ok, I'll remove the comments. But there is no auth-userdb socket in the sockets directtory of dovecot.
}}
to the dovecot.conf.
Well, that looks OK to me; but the only way to test it is to manually run dovecot-lda as vmail. Is there an auth-userdb socket in your dovecot sockets directory? Does it have the right permissions?
No, no such socket in /var/run/dovecot
# ll insgesamt 4 srwxrwxrwx 1 root root 0 8. Jun 2012 dict-server drwxr-x--- 2 root dovecot 4096 22. Jun 19:58 login
How does dovecot know there is a socket in /var/spool/postfix/private/dovecot? And how does dovecot-lda know to look there. Am I missunderstanding something?
Yes, you are misunderstanding something. It works (something) like this:
- A mail comes in to Postfix. - Postfix decides this mail is local. - Postfix sends the mail through /var/spool/postfix/private/dovecot to a Postfix pipe(8) process on the other end. - That pipe(8) process runs dovecot-lda, as the vmail user. - dovecot-lda reads dovecot.conf. - dovecot-lda contacts the Dovecot auth process using the auth-userdb socket. - If the user exists, it delivers the mail to their mailbox.No Dovecot process needs to know anything at all about the Postfix socket, it's just for internal communication between different bits of Postfix. Have you read the Postfix documentation?
Thank you for that explanation!
I am lost. I don't if the mail is handed over to dovecot-lda and if so why it can't find the passwd-file.
If the mail was handed over to dovecot-lda, it ought to be logging *something*. Find out where those logs should go; if they aren't appearing, you need to fix that. Syslog is IMHO a better bet than custom log files.
I have a dovecot-lda-errors.log and a dovecot-lda.log
# cat dovecot-lda-errors.log Dec 14 23:28:20 lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: No such file or directory Dec 14 23:28:20 lda: Fatal: Internal error occurred. Refer to server log for more information.
# echo "foo" | /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de
# cat dovecot-lda.log Dec 14 21:04:07 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX' Dec 14 21:16:46 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX' Dec 14 21:18:25 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX' Dec 14 21:20:44 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX' Dec 14 21:58:13 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX' Dec 15 10:14:50 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX' Dec 15 10:14:59 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX' Dec 15 10:24:19 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX' Dec 15 10:24:27 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX' Dec 15 11:14:58 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX' Dec 15 11:26:01 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX' Dec 15 11:26:11 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX' Dec 15 14:07:40 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX'
So the question is how do I get this auth-userdb socket?
Ben
Andreas
Andreas Meyer anmeyer@anup.de wrote:
Well, that looks OK to me; but the only way to test it is to manually run dovecot-lda as vmail. Is there an auth-userdb socket in your dovecot sockets directory? Does it have the right permissions?
No, no such socket in /var/run/dovecot
I just found out the sockets of dovecot reside in /usr/var/run/dovecot
# ll insgesamt 16 srw------- 1 root root 0 15. Dez 11:14 anvil srw------- 1 root root 0 15. Dez 11:14 anvil-auth-penalty srw------- 1 root root 0 15. Dez 11:14 auth-client srw------- 1 dovecot root 0 15. Dez 11:14 auth-login srw------- 1 root root 0 15. Dez 11:14 auth-master srw------- 1 vmail vmail 0 15. Dez 11:14 auth-userdb srw------- 1 dovecot root 0 15. Dez 11:14 auth-worker srw------- 1 root root 0 15. Dez 11:14 config srw------- 1 root root 0 15. Dez 11:14 dict srw------- 1 root root 0 15. Dez 11:14 director-admin srw-rw-rw- 1 root root 0 15. Dez 11:14 dns-client srw------- 1 root root 0 15. Dez 11:14 doveadm-server lrwxrwxrwx 1 root root 29 15. Dez 11:14 dovecot.conf -> /usr/etc/dovecot/dovecot.conf drwxr-xr-x 2 root root 4096 8. Jun 2012 empty srw-rw-rw- 1 root root 0 15. Dez 11:14 indexer srw------- 1 dovecot root 0 15. Dez 11:14 indexer-worker srw------- 1 root root 0 15. Dez 11:14 ipc srw-rw-rw- 1 root root 0 15. Dez 11:14 lmtp srw------- 1 root root 0 15. Dez 11:14 log-errors drwxr-x--- 2 root dovenull 4096 15. Dez 11:14 login -rw------- 1 root root 6 15. Dez 11:14 master.pid -rw-r--r-- 1 root root 37 15. Dez 11:14 mounts srw------- 1 root root 0 15. Dez 11:14 replication-notify prw------- 1 root root 0 15. Dez 11:14 replication-notify-fifo srw------- 1 dovecot root 0 15. Dez 11:14 replicator srw------- 1 root root 0 15. Dez 11:14 stats prw------- 1 root root 0 15. Dez 11:14 stats-mail
the auth-userdb is there and vmail is the owner. What problem do I have that dovecot-lda does not find the users?
Andreas
At 2PM +0100 on 15/12/12 Andreas Meyer wrote:
[Ben Morrow wrote:]
Well, that looks OK to me; but the only way to test it is to manually run dovecot-lda as vmail. Is there an auth-userdb socket in your dovecot sockets directory? Does it have the right permissions?
No, no such socket in /var/run/dovecot
# ll insgesamt 4 srwxrwxrwx 1 root root 0 8. Jun 2012 dict-server drwxr-x--- 2 root dovecot 4096 22. Jun 19:58 login
If I were to ask 'is anything listening on those sockets?' is there any chance you could answer that?
<snip> > > If the mail was handed over to dovecot-lda, it ought to be logging > > *something*. Find out where those logs should go; if they aren't > > appearing, you need to fix that. Syslog is IMHO a better bet than custom > > log files. > > I have a dovecot-lda-errors.log and a dovecot-lda.log > > # cat dovecot-lda-errors.log > Dec 14 23:28:20 lda: Error: userdb lookup: > connect(/var/run/dovecot/auth-userdb) failed: No such file or > directory > Dec 14 23:28:20 lda: Fatal: Internal error occurred. Refer to server > log for more information.
At 2PM +0100 on 15/12/12 Andreas Meyer wrote:
I just found out the sockets of dovecot reside in /usr/var/run/dovecot
OK, that's... a little bizarre.
That's not where dovecot-lda is looking, at least not according to the log above. Is the vmail user able to read dovecot.conf? Do you have more than one dovecot.conf, with different settings in? I would ask you to run
doveconf -m lda base_dir auth_socket_pathas the vmail user, but I'm not convinced you know how.
Ben
Ben Morrow ben@morrow.me.uk wrote:
At 2PM +0100 on 15/12/12 Andreas Meyer wrote:
[Ben Morrow wrote:]
Well, that looks OK to me; but the only way to test it is to manually run dovecot-lda as vmail. Is there an auth-userdb socket in your dovecot sockets directory? Does it have the right permissions?
No, no such socket in /var/run/dovecot
# ll insgesamt 4 srwxrwxrwx 1 root root 0 8. Jun 2012 dict-server drwxr-x--- 2 root dovecot 4096 22. Jun 19:58 login
If I were to ask 'is anything listening on those sockets?' is there any chance you could answer that?
Nothing is listening on /var/run/dovecot. It must be a relict from the old version 1.x
# netstat -lnp |grep dovecot
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 25542/dovecot
tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 25542/dovecot
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 25542/dovecot
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 25542/dovecot
tcp 0 0 0.0.0.0:4190 0.0.0.0:* LISTEN 25542/dovecot
tcp 0 0 :::993 :::* LISTEN 25542/dovecot
tcp 0 0 :::995 :::* LISTEN 25542/dovecot
tcp 0 0 :::110 :::* LISTEN 25542/dovecot
tcp 0 0 :::143 :::* LISTEN 25542/dovecot
tcp 0 0 :::4190 :::* LISTEN 25542/dovecot
unix 2 [ ACC ] STREAM HÖRT 3425398 24015/master private/dovecot
unix 2 [ ACC ] STREAM HÖRT 3441242 25542/dovecot /usr/var/run/dovecot/login/sieve
unix 2 [ ACC ] STREAM HÖRT 3441249 25542/dovecot /usr/var/run/dovecot/login/ssl-params
unix 2 [ ACC ] STREAM HÖRT 3441260 25542/dovecot /usr/var/run/dovecot/login/pop3
unix 2 [ ACC ] STREAM HÖRT 3441278 25542/dovecot /usr/var/run/dovecot/login/ipc-proxy
unix 2 [ ACC ] STREAM HÖRT 3441288 25542/dovecot /usr/var/run/dovecot/login/imap
unix 2 [ ACC ] STREAM HÖRT 3441302 25542/dovecot /usr/var/run/dovecot/login/dns-client
unix 2 [ ACC ] STREAM HÖRT 3441316 25542/dovecot /usr/var/run/dovecot/login/login
unix 2 [ ACC ] STREAM HÖRT 3441246 25542/dovecot /usr/var/run/dovecot/stats
unix 2 [ ACC ] STREAM HÖRT 3441253 25542/dovecot /usr/var/run/dovecot/replicator
unix 2 [ ACC ] STREAM HÖRT 3441257 25542/dovecot /usr/var/run/dovecot/replication-notify
unix 2 [ ACC ] STREAM HÖRT 3441268 25542/dovecot /usr/var/run/dovecot/log-errors
unix 2 [ ACC ] STREAM HÖRT 3441272 25542/dovecot /usr/var/run/dovecot/lmtp
unix 2 [ ACC ] STREAM HÖRT 3441276 25542/dovecot /usr/var/run/dovecot/ipc
unix 2 [ ACC ] STREAM HÖRT 3441282 25542/dovecot /usr/var/run/dovecot/indexer-worker
unix 2 [ ACC ] STREAM HÖRT 3441286 25542/dovecot /usr/var/run/dovecot/indexer
unix 2 [ ACC ] STREAM HÖRT 3441296 25542/dovecot /usr/var/run/dovecot/doveadm-server
unix 2 [ ACC ] STREAM HÖRT 3441300 25542/dovecot /usr/var/run/dovecot/dns-client
unix 2 [ ACC ] STREAM HÖRT 3441306 25542/dovecot /usr/var/run/dovecot/director-admin
unix 2 [ ACC ] STREAM HÖRT 3441310 25542/dovecot /usr/var/run/dovecot/dict
unix 2 [ ACC ] STREAM HÖRT 3441314 25542/dovecot /usr/var/run/dovecot/config
unix 2 [ ACC ] STREAM HÖRT 3441320 25542/dovecot /usr/var/run/dovecot/auth-login
unix 2 [ ACC ] STREAM HÖRT 3441324 25542/dovecot /usr/var/run/dovecot/auth-client
unix 2 [ ACC ] STREAM HÖRT 3441328 25542/dovecot /usr/var/run/dovecot/auth-userdb
unix 2 [ ACC ] STREAM HÖRT 3441332 25542/dovecot /usr/var/run/dovecot/auth-master
unix 2 [ ACC ] STREAM HÖRT 3441336 25542/dovecot /usr/var/run/dovecot/auth-worker
unix 2 [ ACC ] STREAM HÖRT 3441340 25542/dovecot /usr/var/run/dovecot/anvil
unix 2 [ ACC ] STREAM HÖRT 3441344 25542/dovecot /usr/var/run/dovecot/anvil-auth-penalty
<snip> > > If the mail was handed over to dovecot-lda, it ought to be logging > > *something*. Find out where those logs should go; if they aren't > > appearing, you need to fix that. Syslog is IMHO a better bet than custom > > log files. > > I have a dovecot-lda-errors.log and a dovecot-lda.log > > # cat dovecot-lda-errors.log > Dec 14 23:28:20 lda: Error: userdb lookup: > connect(/var/run/dovecot/auth-userdb) failed: No such file or > directory > Dec 14 23:28:20 lda: Fatal: Internal error occurred. Refer to server > log for more information.
At 2PM +0100 on 15/12/12 Andreas Meyer wrote:
I just found out the sockets of dovecot reside in /usr/var/run/dovecot
OK, that's... a little bizarre.
That's not where dovecot-lda is looking, at least not according to the log above. Is the vmail user able to read dovecot.conf? Do you have more than one dovecot.conf, with different settings in? I would ask you to run
doveconf -m lda base_dir auth_socket_pathas the vmail user, but I'm not convinced you know how.
I can run it as root but not as vmail
# su vmail doveconf -m lda base_dir auth_socket_path /usr/bin/doveconf: /usr/bin/doveconf: cannot execute binary file
# doveconf -m lda base_dir auth_socket_path base_dir = /usr/var/run/dovecot auth_socket_path = auth-userdb
You are great! So the problem is dovecot-lda does not find the sockets. Can I tell it to look in /usr/var/run/dovecot?
Ben
Andreas
Ben Morrow ben@morrow.me.uk wrote:
That's not where dovecot-lda is looking, at least not according to the log above. Is the vmail user able to read dovecot.conf? Do you have more than one dovecot.conf, with different settings in? I would ask you to run
doveconf -m lda base_dir auth_socket_pathas the vmail user, but I'm not convinced you know how.
I managed to su to vmail by giving it a shell.
# su - vmail vmail@delta:~> doveconf -m lda base_dir auth_socket_path base_dir = /usr/var/run/dovecot auth_socket_path = auth-userdb
But I don't know how to tell dovecot-lda to listen on sockets in /usr/var/run/dovecot
Ben
Andreas
At 3PM +0100 on 15/12/12 you (Andreas Meyer) wrote:
Ben Morrow ben@morrow.me.uk wrote:
That's not where dovecot-lda is looking, at least not according to the log above. Is the vmail user able to read dovecot.conf? Do you have more than one dovecot.conf, with different settings in? I would ask you to run
doveconf -m lda base_dir auth_socket_pathas the vmail user, but I'm not convinced you know how.
I managed to su to vmail by giving it a shell.
# su - vmail vmail@delta:~> doveconf -m lda base_dir auth_socket_path base_dir = /usr/var/run/dovecot auth_socket_path = auth-userdb
But I don't know how to tell dovecot-lda to listen on sockets in /usr/var/run/dovecot
Do you mean 'connect to'? It's important to be clear.
The first thing is to see what actually happens when you invoke dovecot-lda as vmail. Remember to check the logs as well as the mailboxes.
Ben
Ben Morrow ben@morrow.me.uk wrote:
# su - vmail vmail@delta:~> doveconf -m lda base_dir auth_socket_path base_dir = /usr/var/run/dovecot auth_socket_path = auth-userdb
But I don't know how to tell dovecot-lda to listen on sockets in /usr/var/run/dovecot
Do you mean 'connect to'? It's important to be clear.
hm, what does dovecot-lda do? I think it tries to connect to /usr/var/run/dovecot/auth-userdb ?
The first thing is to see what actually happens when you invoke dovecot-lda as vmail. Remember to check the logs as well as the mailboxes.
vmail@delta:~> echo "foo" | /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de
The email with body foo in it is delivered to the mailbox. Dec 15 16:37:27 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX'
Sending an email from the desktop results in the same error:
# mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- CB9771B3025F 559 Sat Dec 15 16:39:48 anmeyer@anup.de (unknown user: "anmeyer@anup.de") anmeyer@anup.de
I looked at the makefiles in the sources of the installed version of dovecot and found that dovecot-lda is like everything compiled with localstatedir = ${prefix}/var rundir = ${prefix}/var/run/dovecot statedir = ${prefix}/var/lib/dovecot where prefix = /usr
I don't know why dovecot-lda is not connecting? to /usr/var/run/dovecot/auth-userdb and instead uses /var/run/dovecot. I delete /var/run/dovecot meanwhile.
Ben
Andreas
Andreas Meyer wrote:
Ben Morrow ben@morrow.me.uk wrote:
# su - vmail vmail@delta:~> doveconf -m lda base_dir auth_socket_path base_dir = /usr/var/run/dovecot auth_socket_path = auth-userdb
But I don't know how to tell dovecot-lda to listen on sockets in /usr/var/run/dovecot
Do you mean 'connect to'? It's important to be clear.
hm, what does dovecot-lda do? I think it tries to connect to /usr/var/run/dovecot/auth-userdb ?
Try to trace the open syscalls of dovecot-lda and its children:
strace -f -eopen /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de
This should give you an idea about which files dovecot-lda really tries to open.
Regards Daniel
Hello!
Daniel Parthey daniel.parthey@informatik.tu-chemnitz.de wrote:
Andreas Meyer wrote:
Ben Morrow ben@morrow.me.uk wrote:
# su - vmail vmail@delta:~> doveconf -m lda base_dir auth_socket_path base_dir = /usr/var/run/dovecot auth_socket_path = auth-userdb
But I don't know how to tell dovecot-lda to listen on sockets in /usr/var/run/dovecot
Do you mean 'connect to'? It's important to be clear.
hm, what does dovecot-lda do? I think it tries to connect to /usr/var/run/dovecot/auth-userdb ?
Try to trace the open syscalls of dovecot-lda and its children:
strace -f -eopen /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de
# strace -f -eopen /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de open("/usr/lib/dovecot/tls/i686/sse2/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/tls/i686/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/tls/sse2/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/tls/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/i686/sse2/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/i686/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/sse2/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/libdovecot-lda.so.0", O_RDONLY) = 3 open("/usr/lib/dovecot/libdovecot-storage.so.0", O_RDONLY) = 3 open("/usr/lib/dovecot/libdovecot.so.0", O_RDONLY) = 3 open("/usr/lib/dovecot/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libc.so.6", O_RDONLY) = 3 open("/usr/lib/dovecot/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/librt.so.1", O_RDONLY) = 3 open("/usr/lib/dovecot/libssl.so.0.9.8", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libssl.so.0.9.8", O_RDONLY) = 3 open("/usr/lib/dovecot/libcrypto.so.0.9.8", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libcrypto.so.0.9.8", O_RDONLY) = 3 open("/usr/lib/dovecot/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libz.so.1", O_RDONLY) = 3 open("/usr/lib/dovecot/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libdl.so.2", O_RDONLY) = 3 open("/lib/libpthread.so.0", O_RDONLY) = 3 open("/var/log/dovecot-lda-errors.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = 6 open("/var/log/dovecot-lda.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = 7 open("/usr/lib/dovecot", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 8 open("/usr/lib/dovecot/lib90_sieve_plugin.so", O_RDONLY) = 8 open("/usr/lib/dovecot/libdovecot-sieve.so.0", O_RDONLY) = 8 open("/var/log/dovecot-lda-errors.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = 6 open("/var/log/dovecot-lda.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = 7
This should give you an idea about which files dovecot-lda really tries to open.
Can't really say there is something wrong. It seems to find everything it is looking for.
Regards Daniel
Andreas
Andreas Meyer wrote:
hm, what does dovecot-lda do? I think it tries to connect to /usr/var/run/dovecot/auth-userdb ?
Try to trace the open syscalls of dovecot-lda and its children:
strace -f -eopen /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de
# strace -f -eopen /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de open("/usr/lib/dovecot/tls/i686/sse2/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/tls/i686/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/tls/sse2/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/tls/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/i686/sse2/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/i686/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/sse2/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/libdovecot-lda.so.0", O_RDONLY) = 3 open("/usr/lib/dovecot/libdovecot-storage.so.0", O_RDONLY) = 3 open("/usr/lib/dovecot/libdovecot.so.0", O_RDONLY) = 3 open("/usr/lib/dovecot/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libc.so.6", O_RDONLY) = 3 open("/usr/lib/dovecot/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/librt.so.1", O_RDONLY) = 3 open("/usr/lib/dovecot/libssl.so.0.9.8", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libssl.so.0.9.8", O_RDONLY) = 3 open("/usr/lib/dovecot/libcrypto.so.0.9.8", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libcrypto.so.0.9.8", O_RDONLY) = 3 open("/usr/lib/dovecot/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libz.so.1", O_RDONLY) = 3 open("/usr/lib/dovecot/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libdl.so.2", O_RDONLY) = 3 open("/lib/libpthread.so.0", O_RDONLY) = 3 open("/var/log/dovecot-lda-errors.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = 6 open("/var/log/dovecot-lda.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = 7 open("/usr/lib/dovecot", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 8 open("/usr/lib/dovecot/lib90_sieve_plugin.so", O_RDONLY) = 8 open("/usr/lib/dovecot/libdovecot-sieve.so.0", O_RDONLY) = 8 open("/var/log/dovecot-lda-errors.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = 6 open("/var/log/dovecot-lda.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = 7
Of course you will need to deliver a mail via stdin. Otherwise dovecot-lda will stall and wait for input, it doesn't even try to connect to auth-userdb.
This might work:
echo "foo" | strace -f -eopen /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de
Regards Daniel
Andreas Meyer wrote:
hm, what does dovecot-lda do? I think it tries to connect to /usr/var/run/dovecot/auth-userdb ?
Try to trace the open syscalls of dovecot-lda and its children:
strace -f -eopen /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de
This should give you an idea about which files dovecot-lda really tries to open.
Can't really say there is something wrong. It seems to find everything it is looking for.
You can also replace the -eopen with -efile to trace all file syscalls.
echo "foo" | strace -f -efile /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de
Daniel Parthey daniel.parthey@informatik.tu-chemnitz.de wrote:
Andreas Meyer wrote:
hm, what does dovecot-lda do? I think it tries to connect to /usr/var/run/dovecot/auth-userdb ?
Try to trace the open syscalls of dovecot-lda and its children:
strace -f -eopen /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de
This should give you an idea about which files dovecot-lda really tries to open.
Can't really say there is something wrong. It seems to find everything it is looking for.
You can also replace the -eopen with -efile to trace all file syscalls.
echo "foo" | strace -f -efile /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de
# echo "foo" | strace -f -efile /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de execve("/usr/libexec/dovecot/dovecot-lda", ["/usr/libexec/dovecot/dovecot-lda", "-f", "anmeyer@anup.de", "-d", "anmeyer@anup.de"], [/* 57 vars */]) = 0 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/tls/i686/sse2/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/dovecot/tls/i686/sse2", 0xbf901578) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/tls/i686/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/dovecot/tls/i686", 0xbf901578) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/tls/sse2/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/dovecot/tls/sse2", 0xbf901578) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/tls/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/dovecot/tls", 0xbf901578) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/i686/sse2/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/dovecot/i686/sse2", 0xbf901578) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/i686/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/dovecot/i686", 0xbf901578) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/sse2/libdovecot-lda.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/dovecot/sse2", 0xbf901578) = -1 ENOENT (No such file or directory) open("/usr/lib/dovecot/libdovecot-lda.so.0", O_RDONLY) = 3 open("/usr/lib/dovecot/libdovecot-storage.so.0", O_RDONLY) = 3 open("/usr/lib/dovecot/libdovecot.so.0", O_RDONLY) = 3 open("/usr/lib/dovecot/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libc.so.6", O_RDONLY) = 3 open("/usr/lib/dovecot/librt.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/librt.so.1", O_RDONLY) = 3 open("/usr/lib/dovecot/libssl.so.0.9.8", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libssl.so.0.9.8", O_RDONLY) = 3 open("/usr/lib/dovecot/libcrypto.so.0.9.8", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libcrypto.so.0.9.8", O_RDONLY) = 3 open("/usr/lib/dovecot/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libz.so.1", O_RDONLY) = 3 open("/usr/lib/dovecot/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libdl.so.2", O_RDONLY) = 3 open("/lib/libpthread.so.0", O_RDONLY) = 3 open("/var/log/dovecot-lda-errors.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = 8 open("/var/log/dovecot-lda.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = 9 open("/usr/lib/dovecot", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 10 open("/usr/lib/dovecot/lib90_sieve_plugin.so", O_RDONLY) = 10 open("/usr/lib/dovecot/libdovecot-sieve.so.0", O_RDONLY) = 10 open("/var/log/dovecot-lda-errors.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = 8 open("/var/log/dovecot-lda.log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = 9 chdir("/var/spool/vhosts/anup.de/anmeyer") = 0 stat64("/var/spool/vhosts/anup.de/anmeyer", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 open("/etc/localtime", O_RDONLY) = 11 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2295, ...}) = 0 lstat64("/var/spool/vhosts/anup.de/anmeyer/.dovecot.sieve", {st_mode=S_IFLNK|0777, st_size=25, ...}) = 0 stat64("/var/spool/vhosts/anup.de/anmeyer/.dovecot.sieve", {st_mode=S_IFREG|0600, st_size=111, ...}) = 0 open("/var/spool/vhosts/anup.de/anmeyer/.dovecot.svbin", O_RDONLY|O_LARGEFILE) = 11 stat64("/var/spool/vhosts/anup.de/anmeyer/tmp", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 stat64("/var/spool/vhosts/anup.de/anmeyer", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 stat64("/var/spool/vhosts/anup.de/anmeyer", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 open("/var/spool/vhosts/anup.de/anmeyer/dovecot.index.log", O_RDWR|O_LARGEFILE) = 12 open("/var/spool/vhosts/anup.de/anmeyer/dovecot.index", O_RDWR|O_LARGEFILE) = 13 open("/var/spool/vhosts/anup.de/anmeyer/tmp/1355597452.M328355P30049.delta", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0777) = 14 open("/var/spool/vhosts/anup.de/anmeyer/dovecot.index.cache", O_RDWR|O_LARGEFILE) = 15 lstat64("/var/spool/vhosts/anup.de/anmeyer/dovecot-uidlist.lock", 0xbf90145c) = -1 ENOENT (No such file or directory) open("/var/spool/vhosts/anup.de/anmeyer/dovecot-uidlist.lock", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = 14 lstat64("/var/spool/vhosts/anup.de/anmeyer/dovecot-uidlist.lock", {st_mode=S_IFREG|0600, st_size=11, ...}) = 0 stat64("/var/spool/vhosts/anup.de/anmeyer/dovecot.index.log", {st_mode=S_IFREG|0600, st_size=11924, ...}) = 0 stat64("/var/spool/vhosts/anup.de/anmeyer/dovecot-uidlist", {st_mode=S_IFREG|0600, st_size=544, ...}) = 0 stat64("/var/spool/vhosts/anup.de/anmeyer/dovecot.index.log.2", {st_mode=S_IFREG|0600, st_size=32908, ...}) = 0 stat64("/var/spool/vhosts/anup.de/anmeyer/dovecot.index.log", {st_mode=S_IFREG|0600, st_size=11924, ...}) = 0 access("/var/spool/vhosts/anup.de/anmeyer/cur", W_OK) = 0 rename("/var/spool/vhosts/anup.de/anmeyer/tmp/1355597452.M328355P30049.delta", "/var/spool/vhosts/anup.de/anmeyer/new/1355597452.M328355P30049.delta,S=4,W=5") = 0 open("/var/spool/vhosts/anup.de/anmeyer/new", O_RDONLY|O_LARGEFILE) = 14 open("/var/spool/vhosts/anup.de/anmeyer/dovecot-uidlist", O_RDWR|O_LARGEFILE) = 14 stat64("/var/spool/vhosts/anup.de/anmeyer/cur", {st_mode=S_IFDIR|0700, st_size=16384, ...}) = 0 stat64("/var/spool/vhosts/anup.de/anmeyer/dovecot.index.log", {st_mode=S_IFREG|0600, st_size=12016, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2295, ...}) = 0 stat64("/var/spool/vhosts/anup.de/anmeyer/dovecot.index.log", {st_mode=S_IFREG|0600, st_size=12076, ...}) = 0 lstat64("/var/spool/vhosts/anup.de/anmeyer/dovecot-uidlist.lock", {st_mode=S_IFREG|0600, st_size=11, ...}) = 0 unlink("/var/spool/vhosts/anup.de/anmeyer/dovecot-uidlist.lock") = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2295, ...}) = 0
I can't see anyhing about auth-userdb. The mail was delivered to the maildir.
Andreas
At 4PM +0100 on 15/12/12 you (Andreas Meyer) wrote:
Ben Morrow ben@morrow.me.uk wrote:
# su - vmail vmail@delta:~> doveconf -m lda base_dir auth_socket_path base_dir = /usr/var/run/dovecot auth_socket_path = auth-userdb
But I don't know how to tell dovecot-lda to listen on sockets in /usr/var/run/dovecot
Do you mean 'connect to'? It's important to be clear.
hm, what does dovecot-lda do? I think it tries to connect to /usr/var/run/dovecot/auth-userdb ?
Yes. It doesn't listen on any sockets at all.
The first thing is to see what actually happens when you invoke dovecot-lda as vmail. Remember to check the logs as well as the mailboxes.
vmail@delta:~> echo "foo" | /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de
The email with body foo in it is delivered to the mailbox. Dec 15 16:37:27 lda(anmeyer@anup.de): Info: sieve: msgid=unspecified: stored mail into mailbox 'INBOX'
Sending an email from the desktop results in the same error:
# mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- CB9771B3025F 559 Sat Dec 15 16:39:48 anmeyer@anup.de (unknown user: "anmeyer@anup.de") anmeyer@anup.de
*Right*. Now we're getting somewhere: it looks like the problem is in your Postfix configuration.
Create a script something like this
#!/bin/sh
echo "--- FROM [$1] TO [$2]" >>/tmp/lda-log
/usr/bin/id >>/tmp/lda-log
/usr/bin/env >>/tmp/lda-log
exec /usr/libexec/dovecot/dovecot-lda -f "$1" -d "$2"(you may need to adjust the paths to id and env; the point is to avoid relying on $PATH) and change the master.cf entry to invoke
/path/to/script ${sender} ${recipient}instead of dovecot-lda. Then deliver some mail and see what, if anything, gets written to /tmp/lda-log.
Ben
Ben Morrow ben@morrow.me.uk wrote:
Sending an email from the desktop results in the same error:
# mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- CB9771B3025F 559 Sat Dec 15 16:39:48 anmeyer@anup.de (unknown user: "anmeyer@anup.de") anmeyer@anup.de
*Right*. Now we're getting somewhere: it looks like the problem is in your Postfix configuration.
Create a script something like this
#!/bin/sh echo "--- FROM [$1] TO [$2]" >>/tmp/lda-log /usr/bin/id >>/tmp/lda-log /usr/bin/env >>/tmp/lda-log exec /usr/libexec/dovecot/dovecot-lda -f "$1" -d "$2"(you may need to adjust the paths to id and env; the point is to avoid relying on $PATH) and change the master.cf entry to invoke
/path/to/script ${sender} ${recipient}instead of dovecot-lda. Then deliver some mail and see what, if anything, gets written to /tmp/lda-log.
Done that, made the script executable, restarted postfix and sent two mails from the desktop. The stuck in the queue, no file lda-log in /tmp.
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/etc/postfix/script.sh ${sender} ${recipient}
Ben
Andreas
At 8PM +0100 on 15/12/12 you (Andreas Meyer) wrote:
Ben Morrow ben@morrow.me.uk wrote:
Create a script something like this
#!/bin/sh echo "--- FROM [$1] TO [$2]" >>/tmp/lda-log /usr/bin/id >>/tmp/lda-log /usr/bin/env >>/tmp/lda-log exec /usr/libexec/dovecot/dovecot-lda -f "$1" -d "$2"(you may need to adjust the paths to id and env; the point is to avoid relying on $PATH) and change the master.cf entry to invoke
/path/to/script ${sender} ${recipient}instead of dovecot-lda. Then deliver some mail and see what, if anything, gets written to /tmp/lda-log.
Done that, made the script executable, restarted postfix and sent two mails from the desktop. The stuck in the queue, no file lda-log in /tmp.
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/etc/postfix/script.sh ${sender} ${recipient}
OK, then I think the problem is entirely on the Postfix side: it's not even attempting to deliver the mail to Dovecot. You need to ask on a Postfix list.
Ben
Ben Morrow ben@morrow.me.uk wrote:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/etc/postfix/script.sh ${sender} ${recipient}
OK, then I think the problem is entirely on the Postfix side: it's not even attempting to deliver the mail to Dovecot. You need to ask on a Postfix list.
And finally I think I found the problem. There is a transportmap in postfix integrated that says:
anup.de virtual .anup.de virtual
I chanched this to
anup.de dovecot .anup.de dovecot
and mail gets delivered. Even when I comment that map, mail is delivered because of virtual_transport = dovecot. Mail never reached the service dovecot because of that transportmap.
You are so great! Thank you all for being so patient and for your help! Now I can go on.
Ben
Andreas
At 8PM +0100 on 15/12/12 you (Andreas Meyer) wrote:
Ben Morrow ben@morrow.me.uk wrote:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/etc/postfix/script.sh ${sender} ${recipient}
OK, then I think the problem is entirely on the Postfix side: it's not even attempting to deliver the mail to Dovecot. You need to ask on a Postfix list.
And finally I think I found the problem. There is a transportmap in postfix integrated that says:
anup.de virtual .anup.de virtual
I chanched this to
anup.de dovecot .anup.de dovecot
and mail gets delivered. Even when I comment that map, mail is delivered because of virtual_transport = dovecot. Mail never reached the service dovecot because of that transportmap.
Before you go any further, please put the virtual_mailbox_maps parameter back with a map of the valid virtual addresses. Otherwise you'll become a backscatter source.
Ben
Ben Morrow ben@morrow.me.uk wrote:
And finally I think I found the problem. There is a transportmap in postfix integrated that says:
anup.de virtual .anup.de virtual
I chanched this to
anup.de dovecot .anup.de dovecot
and mail gets delivered. Even when I comment that map, mail is delivered because of virtual_transport = dovecot. Mail never reached the service dovecot because of that transportmap.
Before you go any further, please put the virtual_mailbox_maps parameter back with a map of the valid virtual addresses. Otherwise you'll become a backscatter source.
Do you mean the old virtual_mailbox_maps = hash:/etc/postfix/vmailbox ? But wouldn't that mean I have to care for two user files? vmailbox and the passwd-file of dovecot?
Ben
Andreas
At 9PM +0100 on 15/12/12 Andreas Meyer wrote:
Ben Morrow ben@morrow.me.uk wrote:
Before you go any further, please put the virtual_mailbox_maps parameter back with a map of the valid virtual addresses. Otherwise you'll become a backscatter source.
Do you mean the old virtual_mailbox_maps = hash:/etc/postfix/vmailbox ? But wouldn't that mean I have to care for two user files? vmailbox and the passwd-file of dovecot?
It doesn't matter how you do it, but you need to reject invalid users during the SMTP transaction rather than allowing the mail to bounce later. (This is really basic stuff: have you read through the Postfix documentation? It make this pretty clear.)
If you're using a passwd-file userdb in Dovecot, you need to write a script to convert it to a Postfix map, and make sure that script gets run whenever the source file is updated. (Makefiles are good for that sort of thing.) Alternatively, you could switch to keeping your userdb in an SQL or LDAP database, and have Postfix query it directly. If all else fails, you can arrange to pass the output of 'doveadm user "*"' to postmap, though depending on your Dovecot setup you may need to append a domain.
Ben
Ben Morrow ben@morrow.me.uk wrote:
At 9PM +0100 on 15/12/12 Andreas Meyer wrote:
Ben Morrow ben@morrow.me.uk wrote:
Before you go any further, please put the virtual_mailbox_maps parameter back with a map of the valid virtual addresses. Otherwise you'll become a backscatter source.
Do you mean the old virtual_mailbox_maps = hash:/etc/postfix/vmailbox ? But wouldn't that mean I have to care for two user files? vmailbox and the passwd-file of dovecot?
It doesn't matter how you do it, but you need to reject invalid users during the SMTP transaction rather than allowing the mail to bounce later. (This is really basic stuff: have you read through the Postfix documentation? It make this pretty clear.)
Yes, this is clear to me and I also read through the dovecot-wiki a bit and especially LDA and LDA-Posfix. ;)
If you're using a passwd-file userdb in Dovecot, you need to write a script to convert it to a Postfix map, and make sure that script gets run whenever the source file is updated. (Makefiles are good for that sort of thing.) Alternatively, you could switch to keeping your userdb in an SQL or LDAP database, and have Postfix query it directly. If all else fails, you can arrange to pass the output of 'doveadm user "*"' to postmap, though depending on your Dovecot setup you may need to append a domain.
Thank you for your hints, Ben! I am glad I have that thing up and running at least. And I already converted the old vmailbox file that postfix used to a new one with the valid users so postfix knows them too.
Thinking about SQL or LDAP database is one of the next steps I am considering. We don't have that much users and taking care of them is not that much work.
Next thing is I want to implement Quota. We are running users with maildir and mboxes. And of course I want to realize sieve filtering soon or later.
I am glad I got this right now with your help. And learned much again.
Ben
Andreas
Andreas Meyer wrote:
I managed to su to vmail by giving it a shell. # su - vmail
For security reasons, you should rather not give a login shell to non-interactive users.
You can temporarily pass a shell to su:
su -s /bin/sh - vmail
Regards Daniel
At 5PM +0100 on 15/12/12 Daniel Parthey wrote:
Andreas Meyer wrote:
I managed to su to vmail by giving it a shell. # su - vmail
For security reasons, you should rather not give a login shell to non-interactive users.
[This is good advice.]
You can temporarily pass a shell to su:
su -s /bin/sh - vmail
That depends on your su. Mine won't do that. I believe your assumption that Andreas is on Linux, and therefore has a su that does do that, is correct, but I don't know. (I might assume that since I said earlier 'read your system's su(1)' that it doesn't; but then again I might not...)
Ben
Ben Morrow ben@morrow.me.uk wrote:
At 5PM +0100 on 15/12/12 Daniel Parthey wrote:
Andreas Meyer wrote:
I managed to su to vmail by giving it a shell. # su - vmail
For security reasons, you should rather not give a login shell to non-interactive users.
[This is good advice.]
You can temporarily pass a shell to su:
su -s /bin/sh - vmail
That depends on your su. Mine won't do that. I believe your assumption that Andreas is on Linux, and therefore has a su that does do that, is correct, but I don't know. (I might assume that since I said earlier 'read your system's su(1)' that it doesn't; but then again I might not...)
Yes it does. man su says so too.
Ben
Hello!
Ben Morrow ben@morrow.me.uk wrote:
At 5PM +0100 on 14/12/12 Andreas Meyer wrote:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/dovecot-lda -f ${sender} -d ${recipient}
What happens if you run
echo "foo" | /usr/libexec/dovecot/dovecot-lda \ -f xyz@anup.de -d xyz@anup.de
# id vmail uid=5000(vmail) gid=5000(vmail) Gruppen=5000(vmail)
# su vmail echo "foo" | /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de an empty email with 0 B gets delivered to the maildir of anmeyer@anup.de
# echo "foo" | /usr/libexec/dovecot/dovecot-lda -f anmeyer@anup.de -d anmeyer@anup.de email with foo in the body is delivered to the maildir.
# delta:/var/spool/vhosts/anup.de/anmeyer/new # ll insgesamt 4 -rw------- 1 vmail vmail 0 15. Dez 11:26 1355567160.M902698P23725.delta,S=0,W=0 -rw------- 1 vmail vmail 4 15. Dez 11:26 1355567171.M334599P23728.delta,S=4,W=5
in the shell (as the vmail user)? Does it fail with exit code 67? This is EX_NOUSER, and is the standard way for LDAs to signal 'I don't know how to deliver to this user'. Either xyz@anup.de is not a valid address at that domain, or you haven't made the auth-userdb socket available to the vmail user. See http://wiki2.dovecot.org/LDA, under the section 'Virtual users'.
I already added
service auth { unix_listener auth-userdb { mode = 0600 user = vmail # User running dovecot-lda group = vmail # Or alternatively mode 0660 + dovecot-lda user in this group } }
to the dovecot.conf. How does dovecot know there is a socket in /var/spool/postfix/private/dovecot? And how does dovecot-lda know to look there. Am I missunderstanding something?
If I send an email from the desktop I have in the mail.log Dec 15 11:35:25 delta postfix/virtual[23910]: E0BC61B3128A: to=anmeyer@anup.de, relay=virtual, delay=0.18, delays=0.09/0.01/0/0.09, dsn=4.1.1, status=SOFTBOUNCE (unknown user: "anmeyer@anup.de")
and the mail is stuck in the queue # mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- E0BC61B3128A 559 Sat Dec 15 11:35:24 anmeyer@anup.de (unknown user: "anmeyer@anup.de") anmeyer@anup.de
I am lost. I don't if the mail is handed over to dovecot-lda and if so why it can't find the passwd-file.
Ben
Andreas
participants (3)
-
Andreas Meyer
-
Ben Morrow
-
Daniel Parthey