Sieve extprograms pipe :try cancels implicit keep
Hi, When using the :try tag on the pipe command in the sieve_extprograms plugin Sieve’s implicit keep is cancelled if the executed command fails. The specification on https://raw.githubusercontent.com/dovecot/pigeonhole/master/doc/rfc/spec-bosch-sieve-extprograms.txt states: “When the ":try" tag is specified, the "pipe" instruction will attempt execution of the external program, but failure will not cause the whole Sieve script execution to fail with an error. Instead, the Sieve processing continues as if the "pipe" action was never triggered." However, using the :try tag marks the pip command as successful even if it fails and because pipe is a disposition-type action the implicit keep is cancelled, resulting in the piped message being discarded. If this is the intended behaviour then I would suggest amending the text of the specification to: “When the ":try" tag is specified, the "pipe" instruction will attempt execution of the external program, but failure will not cause the whole Sieve script execution to fail with an error. Instead, the Sieve processing continues as if the "pipe" action was executed successfully and cancel implicit keep.” If this is not the intended behaviour then please consider this a bug report, with my apologies for not adding a patch (it seems to be a bit more complex than just changing the return value of act_pipe_commit). Kind regards, -- Sebastiaan Hoogeveen NederHost https://www.nederhost.nl/ KvK: 34099781 ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot director and keepalived
Hi Steven,
On 14/03/2021, 17:53, "dovecot on behalf of Steven Varco"
wrote:
> Now I’m hitting the issue with the way director determines his „Self IP“ by
> trying to
> bind to all configured director_servers IPs, taking the first one possible.
>
> However this approach only works, when the sysctl setting is:
> net.ipv4.ip_nonlocal_bind=0
> On the other side keepalived needs net.ipv4.ip_nonlocal_bind=1 in order to
> bind the VIP.
This can be fixed by specifying the IP address of the director in the
inet_listener section of the director service, like this:
service director {
### other configuration here ###
inet_listener {
address = 172.20.1.4
port = 9090
}
}
The listener address will be used as the 'self IP' of the director. This also
means that each director will have a slightly different configuration file, but
that should usually not be a problem.
I got this from skimming the source, afaict it is not documented anywhere so
I'm not sure if this behavior can always be relied on in future releases (it
does seem logical to me though).
Kind regards,
--
Sebastiaan Hoogeveen
NederHost
KvK: 34099781
Re: sieve-extdata plugin breaks on pigeonhole 0.5 ish
Hi Ed, On 18/09/2020 23:37, Ed W wrote: Hi, I wonder if someone could give me a little help bringing the sieve-extdata plugin up to date to be usable with latest Dovecot/pigeonhole Trying to use both together at present I get an error: managesieve: Fatal: Couldn't load required plugin /usr/lib/dovecot/sieve/lib90_sieve_extdata_plugin.so: dlopen() failed: /usr/lib/dovecot/sieve/lib90_sieve_extdata_plugin.so: undefined symbol: sieve_sys_error This appears to be due to the change in error handling in pigeonhole 0.5 which appears to have removes the "sieve_sys_error()" and "sieve_sys_warning()" functions I'm unclear how this code should be change (I've commented it out for now - eek). You're not alone, I ran into the same problem a couple of days ago. Applying the patch from my pull request at https://github.com/stephanbosch/sieve-extdata-plugin/pull/1 will probably fix this problem. Kind regards, -- Sebastiaan Hoogeveen NederHost https://www.nederhost.nl KvK: 34099781
[patch] Fix for returning NULL values in SQL dict lookups
Hi,
I noticed a bug doing dict lookups on an SQLite database which had NULL values
in its columns; a segmentation fault occurred, probably due to a null pointer
dereference in str_tabescape. The problem is that sqlite3_column_text returns a
null pointer for column values which are (SQL) NULL. It seems the other
database drivers do something similar. The following patch makes the dict
server check for null pointers and return a 'not found' reply in those cases (I
changed the order around in the decision tree to avoid having to repeat return
values):
diff -Naur dovecot-2.2.24/src/dict/dict-commands.c
dovecot-2.2.24-patched/src/dict/dict-commands.c
--- dovecot-2.2.24/src/dict/dict-commands.c 2016-04-26 15:01:20.0
+0200
+++ dovecot-2.2.24-patched/src/dict/dict-commands.c 2016-05-11
22:04:06.0 +0200
@@ -83,14 +83,14 @@
{
struct dict_connection_cmd *cmd = context;
- if (result->ret > 0) {
+ if (result->ret > 0 && result->value) {
cmd->reply = i_strdup_printf("%c%s\n",
DICT_PROTOCOL_REPLY_OK, str_tabescape(result->value));
- } else if (result->ret == 0) {
- cmd->reply = i_strdup_printf("%c\n",
DICT_PROTOCOL_REPLY_NOTFOUND);
- } else {
+ } else if (result->ret < 0) {
i_error("%s", result->error);
cmd->reply = i_strdup_printf("%c\n", DICT_PROTOCOL_REPLY_FAIL);
+ } else {
+ cmd->reply = i_strdup_printf("%c\n",
DICT_PROTOCOL_REPLY_NOTFOUND);
}
dict_connection_cmds_flush(cmd->conn);
}
Kind regards,
--
Sebastiaan Hoogeveen
NederHost
https://www.nederhost.nl/
KvK: 34099781
[patch] Fix for bug in TLS/SSL for LMTP with chained certificates
Hi, In case of tl;dr: I fixed a bug in TLS support for LMTP which caused chained certificates not to work, and another one which caused certificate read errors to be ignored; the patches are attached to this email. While testing LMTP with TLS and certificate verification by Postfix I discovered that certificate chains are not exchanged properly when using LMTP, even though everything works fine for POP3 and IMAP (both with or without STARTTLS). On LMTP only the server certificate is included in the TLS handshake, no intermediate certificates are provided by the server. The first problem I fixed is that in lib-ssl-iostream/iostream-openssl-context.c errors from the ssl_ctx_use_certificate_chain function are silently ignored because the function returns 0 for a failure but the caller checks for values smaller than 0. This problem is fixed in the tiny patch dovecot-2.2.19-ssl_ctx_certificate_chain_returnvalue.diff. After applying this patch the following error message appears in the logs for LMTP only (IMAP and POP3 still work fine): dovecot: lmtp(20683): Error: SSL context initialization failed, disabling SSL: Can't load SSL certificate: error:0608308E:digital envelope routines:EVP_PKEY_get1_EC_KEY:expecting a ec key It turns out this issue is not related to the reading of the certificate or its associated chain. Somewhere before ssl_ctx_use_certificate_chain is called an error is put in the OpenSSL error queue which is never retrieved. Only after loading the server certificate is the queue checked and because of the previously existing error the chain is not loaded. I think the error is related to setting specific protocol options in ssl_iostream_context_set (which may be different for LMTP than for IMAP or POP3) but I did not investigate this. I made the problem go away by making the following two changes: 1. The ssl_ctx_use_certificate_chain function now empties the OpenSSL error queue before doing its work by calling ERR_get_error() until the queue is empty. 2. The openssl_iostream_error function in a similar fashion empties the queue and returns only the error message for the most recent error (this prevent earlier errors from 'hiding' later/more relevant ones). After applying this second patch LMTP now works properly with certificate chains. Note that this patch makes previously unhandled errors simply 'disappear' from the queue, which may be a Very Bad Thing. I guess there is a more elegant way of handling this "queued error" issue but this works for me now and I'm actually not a C programmer. These two fixes are included in dovecot-2.2.19-lmtp_ssl_bug.diff. I suspect this is the same issue as the one reported by Piotr Rotter to this list on July the 27th. Kind regards, -- Sebastiaan Hoogeveen NederHost https://www.nederhost.nl/ KvK: 34099781 dovecot-2.2.19-ssl_ctx_certificate_chain_returnvalue.diff Description: Binary data dovecot-2.2.19-lmtp_ssl_bug.diff Description: Binary data
