Trying to figure out Proxying with LMTP to a few back end storage servers for quota checking before accepting email delivery on the front end nodes.
If I connect to the back end server directly via telnet, everything works great.
If I use a front-end server to proxy to the back end server, I don't get the same result.
Running 2.2.4 on both front and back end servers.
Any help would be appreciated.
backend dovecot.log: dovecot: lmtp(72274): Error: userdb lookup(user@host*masteruser): Disconnected unexpectedly dovecot: auth: Fatal: master: service(auth): child 72272 killed with signal 11 (core not dumped)
front end dovecot.log:
dovecot: lmtp(7495): Debug: auth input:
user=user@host.comnopassword=<hidden> host=
front end dovecot.conf: lmtp_proxy = yes protocols = lmtp
protocol lmtp { postmaster_address = postmaster@mydomain.com mail_plugins = quota
passdb { args = /usr/local/etc/dovecot/dovecot-sql.conf driver = sql } }
service lmtp {
client_limit = 5
executable = lmtp
idle_kill = 0
process_limit = 0
process_min_avail = 0
protocol = lmtp
service_count = 0
inet_listener lmtp {
address =
port = 2525
}
}
backend dovecot.conf:
auth_master_user_separator = *
lmtp_rcpt_check_quota = yes
passdb {
args = /usr/local/etc/dovecot/dovecot-sql.conf
driver = sql
master = yes
}
userdb {
args = /usr/local/etc/dovecot/dovecot-sql.conf
driver = sql
}
service lmtp {
client_limit = 5
executable = lmtp -L
idle_kill = 0
process_limit = 0
process_min_avail = 0
protocol = lmtp
service_count = 0
inet_listener lmtp {
address =
protocol lmtp { info_log_path = /var/log/dovecot-lmtp.log postmaster_address = postmaster@infowest.com mail_plugins = quota }
Am 03.07.2013 02:20, schrieb Cassidy Larson:
Trying to figure out Proxying with LMTP to a few back end storage servers for quota checking before accepting email delivery on the front end nodes
how does LMTP proxy help here?
you need a policyd at the MTA which rejects the message directly from the client by knowing about quota of the target because after the MTA has accepted it *always* results in a bounce and incoming mailflow is hardly via LMTP
google: "dovceot quota policyd postfix" http://www.dovecot.org/list/dovecot/2009-June/040400.html
On 3.7.2013, at 3.20, Cassidy Larson alandaluz@gmail.com wrote:
dovecot: auth: Fatal: master: service(auth): child 72272 killed with signal 11 (core not dumped)
A crash is always a bug. It would be nice to be able to fix it. A gdb backtrace would be the easiest way to fix it. One possibility would be to a get a core dump, which could be kind of annoyingly difficult since it didn't already happen. One hopefully easier way would be to:
- telnet localhost 143
- In another terminal run: ps aux | grep dovecot/auth; gdb -p <pid of that auth process> cont <do whatever to get the process to crash> bt full
Timo,
Does this give you what you need?
#0 0x00000000131bbdd4 in strcmp () from /lib/libc.so.7 No symbol table info available. #1 0x000000000040d0af in auth_find_service () No symbol table info available. #2 0x0000000000413b38 in auth_request_set_login_username () No symbol table info available. #3 0x0000000000413c72 in auth_request_set_username () No symbol table info available. #4 0x000000000040eedf in ?? () No symbol table info available. #5 0x000000000040f855 in ?? () No symbol table info available. #6 0x00000000108c7a16 in io_loop_call_io () from /usr/local/lib/dovecot/libdovecot.so.0 No symbol table info available. #7 0x00000000108c89d6 in io_loop_handler_run () from /usr/local/lib/dovecot/libdovecot.so.0 No symbol table info available. #8 0x00000000108c79bd in io_loop_run () from /usr/local/lib/dovecot/libdovecot.so.0 No symbol table info available. #9 0x000000001087e443 in master_service_run () from /usr/local/lib/dovecot/libdovecot.so.0 No symbol table info available. #10 0x000000000041bb90 in main () No symbol table info available.
On Tue, Jul 2, 2013 at 7:25 PM, Timo Sirainen tss@iki.fi wrote:
On 3.7.2013, at 3.20, Cassidy Larson alandaluz@gmail.com wrote:
dovecot: auth: Fatal: master: service(auth): child 72272 killed with signal 11 (core not dumped)
A crash is always a bug. It would be nice to be able to fix it. A gdb backtrace would be the easiest way to fix it. One possibility would be to a get a core dump, which could be kind of annoyingly difficult since it didn't already happen. One hopefully easier way would be to:
- telnet localhost 143
- In another terminal run: ps aux | grep dovecot/auth; gdb -p <pid of that auth process> cont <do whatever to get the process to crash> bt full
On 3.7.2013, at 4.50, Cassidy Larson alandaluz@gmail.com wrote:
Timo,
Does this give you what you need?
#0 0x00000000131bbdd4 in strcmp () from /lib/libc.so.7 No symbol table info available. #1 0x000000000040d0af in auth_find_service () No symbol table info available. #2 0x0000000000413b38 in auth_request_set_login_username () No symbol table info available. #3 0x0000000000413c72 in auth_request_set_username () No symbol table info available.
Thanks, this should fix it: http://hg.dovecot.org/dovecot-2.2/rev/aff54366b1b6
participants (3)
-
Cassidy Larson
-
Reindl Harald
-
Timo Sirainen