search for: stderr_rejection

...flags_override_add = MAIL_STORAGE_SERVICE_FLAG_DISALLOW_ROOT, flags_override_remove = (unknown: 0), no_userdb_lookup = 0} storage = 0x1 user_source = 0x56242ac6d3af "" destaddr_source = 0x56242ac6d3af "" process_euid = 5000 stderr_rejection = false ret = <optimized out> c = <optimized out> error = MAIL_ERROR_NONE Thanks in advance for any additional insight that you may be able to provide! -Ben

I'm testing deliver with sendmail and fs quotas. On an over quota condition, deliver accepts the mail, deletes it, then issues a MDN immediately. Is there a way to get deliver to soft fail like procmail does with a 400 error and queue the mail, then let sendmail handle the MDN, following it's "confTO_QUEUEWARN" and "confTO_QUEUERETURN" ? Thanks, Ken -- Ken

...in.so No symbol table info available. #13 0x00007ffff7b69960 in mail_deliver (ctx=0x7fffffffe9e0, storage_r=0x7fffffffe9a8) at mail-deliver.c:498 ??????? muser = 0x555555777ef8 ??????? ret = <optimized out> ??????? __func__ = "mail_deliver" #14 0x0000555555556fd2 in lda_deliver (stderr_rejection=false, rcpt_to_source=<optimized out>, rcpt_to=<optimized out>, path=<optimized out>, user=<optimized out>, ??? service_user=<optimized out>, ctx=0x7fffffffe9e0) at main.c:253 ??????? storage = 0x0 ??????? errstr = 0x0 ??????? ret = <optimized out> ???????...

...ags_override_add = 0, flags_override_remove = 0, no_userdb_lookup = 0} storage = (struct mail_storage *) 0x0 user_source = (const __unknown__ *) 0x4034c0 "" destaddr_source = (const __unknown__ *) 0x403576 "-a parameter" process_euid = 0 stderr_rejection = false ret = 1 c = -1 error = MAIL_ERROR_NONE Cheers, Olivier

...0x00007ffff7b69960 in mail_deliver (ctx=0x7fffffffe9e0, >> storage_r=0x7fffffffe9a8) at mail-deliver.c:498 >> ??????? muser = 0x555555777ef8 >> ??????? ret = <optimized out> >> ??????? __func__ = "mail_deliver" >> #14 0x0000555555556fd2 in lda_deliver (stderr_rejection=false, >> rcpt_to_source=<optimized out>, rcpt_to=<optimized out>, >> path=<optimized out>, user=<optimized out>, >> ??? service_user=<optimized out>, ctx=0x7fffffffe9e0) at main.c:253 >> ??????? storage = 0x0 >> ??????? errstr = 0x0 &gt...

...input = (struct istream *) 0x80f8670 t = (struct mailbox_transaction_context *) 0x8106be8 headers_ctx = (struct mailbox_header_lookup_ctx *) 0x8106508 mail = (struct mail *) 0x8107a48 process_euid = 89 namespace_pool = <value optimized out> stderr_rejection = false keep_environment = false user_auth = true i = 63 ret = <value optimized out> # dovecot -n # 1.1.beta11: /etc/dovecot/dovecot.conf base_dir: /var/run/dovecot/ protocols: imap imaps pop3 pop3s login_dir: /var/run/dovecot/login login_executable(default):...

...available. > #13 0x00007ffff7b69960 in mail_deliver (ctx=0x7fffffffe9e0, > storage_r=0x7fffffffe9a8) at mail-deliver.c:498 > ??????? muser = 0x555555777ef8 > ??????? ret = <optimized out> > ??????? __func__ = "mail_deliver" > #14 0x0000555555556fd2 in lda_deliver (stderr_rejection=false, > rcpt_to_source=<optimized out>, rcpt_to=<optimized out>, > path=<optimized out>, user=<optimized out>, > ??? service_user=<optimized out>, ctx=0x7fffffffe9e0) at main.c:253 > ??????? storage = 0x0 > ??????? errstr = 0x0 > ??????? ret = <...

Hi, while testing out dovecot 1.1, I found that when you set quota_full_tempfail = yes in dovecot.conf and use the deliver -e command line flag, no deferral reason is printed, thus breaking my fancy quota_exceeded_message. This appears to be because of the if() block in lines 1003-1009 in src/deliver/deliver.c, and should be easily fixable (if it is indeed a bug, and not intended behavior).

...mote_port = 0, userdb_fields = 0x0, flags_override_add = 0, flags_override_remove = 0, no_userdb_lookup = 0} storage = (struct mail_storage *) 0x0 user_source = 0x404090 "" destaddr_source = 0x403d73 "-a parameter" process_euid = 0 stderr_rejection = false ret = 1 c = -1 error = MAIL_ERROR_NONE # 2.2.15: /usr/local/etc/dovecot/dovecot.conf # Pigeonhole version 0.4.6 (3e924b1b6c5c+) # OS: FreeBSD 10.0-RELEASE amd64 auth_mechanisms = plain login digest-md5 doveadm_password = welcomemyguest first_valid_gid = 0 first_...

Hello, I'm attempting to capture a core-dump file, and gdb reports warning: core file may not match specified executable file. And only after installing "dovecot-dbg" on my system (Ubuntu 16.04 LTS) does gdb report further warning: the debug information found in "/lib64/ld-2.23.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). It took some

...t> box = 0x85801c0 raw_box = <value optimized out> input = 0x0 t = 0x8584d90 headers_ctx = 0x0 user_source = 0x804ab2c "" sets = <value optimized out> process_euid = <value optimized out> stderr_rejection = false mtime = -1 ret = <value optimized out> c = <value optimized out> error = <value optimized out> Any ideas? Thanks in advance, Sean

I think alpine does not have that https://pkgs.alpinelinux.org/packages?name=dovecot*&branch=v3.8&repo=main&arch=x86_64 https://git.alpinelinux.org/aports/tree/main/dovecot/APKBUILD?h=3.8-stable What else would help? strace? On 2019. 10. 06. 23:05, Stephan Bosch via dovecot wrote: > > > On 06/10/2019 23:03, Demonhost wrote: >> Hi Stephan, >> >> I managed

i'm facing a pretty hard to debug problem when trying to use dovecot LDA (deliver) from postfix. After having all configured, mail deliver fails. This is from my maillog: Feb 12 21:27:54 correio postfix/pipe[12484]: 930F9F6105: to=<solutti at domain.com.br>, relay=dovecot, delay=0.21, delays=0.03/0.01/0/0.18, dsn=4.3.0, status=SOFTBOUNCE (Command died with signal 11:

...unless I'm wrong, that's because Postfix didn't receive neither a "D.S.N text" string nor an EX_* fatal return code. From deliver.c, it seems that many calls to i_fatal() are liable to be executed before the -e option is taken into account (through the local variable stderr_rejection). As a result, I'm wondering under which circumstances exactly deliver is liable to return EX_NOPERM, so that Postfix may consider a permanent failure and bounce the message. Note that the question may somehow be re-phrased as: when invoked without the -e option, under which circumstance...

We uograded our dovecot from version 2.1.10 -> 2.10.12, but within the first hour of use, dovecot-lda would segfault during delivery. This left a lock file lying around causing the user's mail readers to hang; much hilarity ensues. All further deliveries to the same user will result in a crash. The only thing that fixes this condition is to blow away the user's INBOX cache index.