lda fails in parse_angle_addr if sieve is enabled
Hi,
Since updating to 2.3.1 on my FreeBSD mailserver mail delivery using lda is broken if I have sieve enabled. (Before updating this was 2.2 and pigeonhole 0.4)
FreeBSD 11.1-p8 amd64 Dovecot 2.3.1 Pigeonhole 0.5.1
Mailflow is OpenSMTPd as MTA, using mda delivery to rspamc which utlimately delivers using dovecot-lda.
smtpd.conf deliver to mda "rspamc -h scan --mime -e \"/usr/local/libexec/dovecot/deliver -d %{user.username}\"" %{user.username} is the local user after virtusers, aliases etc. verified using a shell wrapper and capturing the username.
conf.d/15-lda.conf protocol lda { mail_plugins = $mail_plugins sieve }
maillog: Apr 8 19:36:54 email smtpd[6390]: smtp-in: Accepted message 9db769b1 on session 81939f0d30337a47: from=<user1@example.org>, to=<user2@example.net>, size=2871, ndest=1, proto=ESMTP Apr 8 19:36:54 email smtpd[6390]: smtp-in: Closing session 81939f0d30337a47 Apr 8 19:36:55 email dovecot: lda(user2)<21091><Ljv6JzdTylpjUgAAWr0fMA>: Panic: file message-address.c: line 147 (parse_angle_addr): assertion failed: (*ctx->parser.data == '<') Apr 8 19:36:55 email smtpd[6390]: delivery: TempFail for 9db769b13edef5a7: from=<user1@example.org>, to=<user2@example.net>, user=bernard, method=mda, delay=1s, stat=Error ("") Apr 8 19:36:57 email smtpd[6390]: smtp-out: Closing session 81939f0c09f5140b: 1 message sent. Apr 8 19:37:04 email dovecot: lda(user2)<21102><vAChMkBTylpuUgAAWr0fMA>: Panic: file message-address.c: line 147 (parse_angle_addr): assertion failed: (*ctx->parser.data == '<') Apr 8 19:37:04 email smtpd[6390]: delivery: TempFail for 9db769b13edef5a7: from=<user1@example.org>, to=<user2@example.net>, user=bernard, method=mda, delay=10s, stat=Error ("")
Removing sieve from mail_plugins configuration and restarting Apr 8 19:37:32 email dovecot: master: Warning: Killed with signal 15 (by pid=21106 uid=0 code=kill) Apr 8 19:37:32 email dovecot: imap(user2)<21085><WGCXullpKzasEQIC>: Server shutting down. in=774 out=5373 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0 Apr 8 19:37:32 email dovecot: master: Dovecot v2.3.1 (8e2f634) starting up for imap, lmtp, sieve Apr 8 19:37:35 email dovecot: lda(user2)<21134><tNPZHl9TylqOUgAAWr0fMA>: msgid=<32984450d041e5c2f887bed5f6512c92@example.org>: saved mail to INBOX Apr 8 19:37:35 email smtpd[6390]: delivery: Ok for 9db769b13edef5a7: from=<user1@example.org>, to=<user2@example.net>, user=user2, method=mda, delay=41s, stat=Delivered
Mail gets delivered.
Don't understand why it is looking for a <>-address if sieve is enabled.
Cheers, Bernard Spil.
Hi all,
Reverted back to 2.2.34 and pigeonhole 0.4.22 and (after reverting config changes) it's working again including Sieve.
I was notified of commit https://github.com/stephanbosch/dovecot-core/commit/6553f20bb31b5f0eebb73a0d... which I'll try. It's in a different option -f (not -d) but will try.
Cheers, Bernard.
2018-04-08 20:10 GMT+02:00 Bernard Spil <brnrd@freebsd.org>:
Hi all,
This patch doesn't fix the issue. Error persists. https://github.com/stephanbosch/dovecot-core/commit/6553f20bb31b5f0eebb73a0d...
Cheers,
Bernard.
2018-04-08 21:26 GMT+02:00 Bernard Spil <brnrd@freebsd.org>:
Op 4/8/2018 om 8:10 PM schreef Bernard Spil:
I found the cause of the panic. However, what actually triggers it could be a little more nasty. Do you have an example of a message passed to dovecot-lda that causes the problem? I am particularly interested in the Return-Path header.
Regards,
Stephan.
Hi Stephan,
Shared the message to you in person only via separate mail.
With to Return-Path, I've not seen any difference in failures, all messages were consistently failing with the same error.
Thank you! Bernard.
2018-04-10 2:54 GMT+02:00 Stephan Bosch <stephan@rename-it.nl>:
Op 11-4-2018 om 20:42 schreef Bernard Spil:
The fix for the panic itself is here:
https://github.com/dovecot/core/commit/fbed9168dc3b104b09bd748409aec902328cd...
Given that you provided an example message without a return-path header, I am confused on how this panic would occur at your end. Are you really sure this is the message that Dovecot gets to see? If you extracted it from the STMP queue, that may not be the same.
You could also obtain a GDB backtrace from dovecot-lda, which would tell
me from which part of the code this panic is reached (I currently see
only one obvious path). You can run dovecot-lda from command line within
GDB to achieve this: gdb --args dovecot-lda -p <message-file> -d <user> and then execute r .. wait until it crashes an then issue 'bt
full` (https://dovecot.org/bugreport.html).
Regards,
Stephan.
participants (2)
-
Bernard Spil
-
Stephan Bosch