HIGHESTMODSEQ replication issue
Hello, I'm using dovecot 2.3.10 in OpenSUSE and I have configured a master/master replication between two backends, it works well but I have found an issue with the replication of the HIGHESTMODSEQ. When I move a set of message from a mailbox to other, e.g. move 3 messages from INBOX to Junk, the HIGHESTMODSEQ get different on each server, with no errors in the log: [Borrador] 34:34 [Sent] 63:63 [Drafts] 12:12 [Trash] 146:146 [Junk] 219:218 [INBOX] 1133:1130 It can be fixed executing a full sync: $ sudo doveadm -D -v sync -u u...@test.priv -d -l 30 -U But it is not a solution because it happens all the time that a user move messages. I'm using ActiveSync and the ActiveSync server use the HIGHESTMODSEQ as part of the synchronization key (sync_key), so in that situation the server detect changes on the mailbox if it connects to the backend with a different HIGHESTMODSEQ that it previously cached, causing a loop beetween the ActiveSync server and the the email client, where the server constantly inform email client about nonexistent changes. Could it be a bug in Dovecot replication? How can I solve it? Best regards, Gustavo Ajeitos
Re: Feature request.
On Fri, 9 Oct 2020, David Morsberger wrote: Both the renew hook and post hook are good candidates for our reload script. Each has a downside however. The post hook will be run after every renewal attempt, regardless of if anything was actually renewed or not. This will result in the services being reloaded many times for no reason. An alternative to using certbot hooks is to use an inotify based tool (available for most Linux based OS). A certificate update triggers a restart script. For example, https://linux.die.net/man/5/incrontab The renew hook only runs if a certificate was successfully renewed, but it will be run once for each certificate. This could mean reloading services multiple times if you have multiple certificates. If you only have a single certificate however it'll work great. For this case, I think you need a periodic (cron) process, restart rather than a synchronous process, that will check certs and restart/reload once per day/week/whatever. This is the method I use as my LE certificates are obtained via DNS challenges on a different host. Joseph Tam
Re: Feature request.
On Fri, Oct 09, 2020 at 07:55:53AM -0400, David Morsberger wrote: > To configure a renew hook, add the following to the configuration file: > > renew-hook = /root/bin/certbot-renew > Next, create the renew hook script at /root/bin/certbot-renew with the > following contents: > > #!/bin/sh > systemctl reload postfix > systemctl reload dovecot My suggestion is that you make a /etc/certbot/reload-hooks/ directory and then use run-parts /etc/certbot/reload-hooks/ as the hook and put #!/bin/sh systemctl reload postfix #!/bin/sh systemctl reload dovecot as separate scritps in there. Now, postfix can come with its own /etc/certbot/reload-hooks/010-postfix and similar for dovecot. And certbot can start shipping with an empty directory and that run-parts preconfigured! Now all that's left is to submit this to the various maintainers so that we don't have to do this manually every time a reinstall happens. Roger. -- ** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** **Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
Re: Feature request.
so if you have a new certificate it is valid vor 89.something days, you could do a: openssl x509 -in file.crt -checkend 7689600 -noout > /dev/null && /usr/bin/systemctl reload dovecot
Re: LMTP Authentication Error
Alexander,
Do you see anything wrong in my config?
David
Sent from my iPhone
> On Oct 7, 2020, at 18:19, David Morsberger wrote:
>
> On 2020-10-07 12:43, Alexander Dalloz wrote:
>>> Am 07.10.2020 um 18:20 schrieb da...@mmpcrofton.com:
>>> Any ideas on how to resolve the Userdb connect/lookup problem? My users are
>>> pinging me on Sieve support.
>>> Thanks,
>>> David
>> Provide a full output of "doveconf -n"?
>> Alexander
>
> Alexandar,
>
> Thanks and here you go.
>
> # 2.3.7.2 (3c910f64b): /etc/dovecot/dovecot.conf
> # Pigeonhole version 0.5.7.2 ()
> # OS: Linux 5.4.0-48-generic x86_64 Ubuntu 20.04.1 LTS
> # Hostname: mmp-mail.mmpcrofton.com
> base_dir = /var/run/dovecot/
> first_valid_uid = 150
> login_greeting = Dovecot ready.
> mail_gid = 150
> mail_location = mbox:~/mail:INBOX=/var/mail/%u
> mail_privileged_group = mail
> mail_uid = 150
> managesieve_notify_capability = mailto
> managesieve_sieve_capability = fileinto reject envelope encoded-character
> vacation subaddress comparator-i;ascii-numeric relational regex imap4flags
> copy include variables body enotify environment mailbox date index ihave
> duplicate mime foreverypart extracttext
> namespace inbox {
> inbox = yes
> location =
> mailbox Drafts {
> auto = subscribe
> special_use = \Drafts
> }
> mailbox Junk {
> auto = subscribe
> special_use = \Junk
> }
> mailbox Sent {
> auto = subscribe
> special_use = \Sent
> }
> mailbox "Sent Messages" {
> auto = no
> special_use = \Sent
> }
> mailbox Spam {
> auto = create
> special_use = \Junk
> }
> mailbox Trash {
> auto = subscribe
> special_use = \Trash
> }
> prefix =
> }
> passdb {
> args = /etc/dovecot/dovecot-sql.conf.ext
> driver = sql
> }
> plugin {
> sieve = file:/home/mail/rules/%u/;active=/home/mail/rules/%u/.dovecot.sieve
> sieve_dir = /home/mail/rules/%u
> }
> protocols = " imap lmtp sieve pop3 sieve"
> service auth {
> unix_listener /var/spool/postfix/private/auth {
> group = postfix
> mode = 0660
> user = postfix
> }
> }
> service lmtp {
> unix_listener /var/spool/postfix/private/dovecot-lmtp {
> group = postfix
> mode = 0600
> user = postfix
> }
> }
> ssl = required
> ssl_cert = ssl_client_ca_dir = /etc/ssl/certs
> ssl_dh = # hidden, use -P to show it
> ssl_key = # hidden, use -P to show it
> userdb {
> driver = prefetch
> }
> userdb {
> args = /etc/dovecot/dovecot-sql.conf.ext
> driver = sql
> }
> protocol lmtp {
> mail_plugins = " sieve"
> postmaster_address = da...@mmpcrofton.com
> }
> protocol imap {
> mail_max_userip_connections = 50
> }
Core dump with search in a virtual folder with FTS enabled
Hi all,
when I try to search in a virtual mailbox with FTS enabled, imap cores dump.
Sample IMAP session in a virtual mailbox:
1 OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT
SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND
URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED
I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH
LIST-STATUS BINARY MOVE SNIPPET=FUZZY PREVIEW=FUZZY STATUS=SIZE SAVEDATE
LITERAL+ NOTIFY] Logged in2 SELECT Search/All* FLAGS (\Answered \Flagged
\Deleted \Seen \Draft)* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen
\Draft \*)] Flags permitted.* 1 EXISTS* 0 RECENT* OK [UNSEEN 1] First unseen.*
OK [UIDVALIDITY 1602234810] UIDs valid* OK [UIDNEXT 2] Predicted next UID2 OK
[READ-WRITE] Select completed (0.002 + 0.000 + 0.001 secs).2 UID SEARCH HEADER
From userConnection closed by foreign host.
When I search in INBOX all OK:
1 OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT
SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND
URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED
I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH
LIST-STATUS BINARY MOVE SNIPPET=FUZZY PREVIEW=FUZZY STATUS=SIZE SAVEDATE
LITERAL+ NOTIFY] Logged in
2 SELECT INBOX* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)* OK
[PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags
permitted.* 1 EXISTS* 0 RECENT* OK [UNSEEN 1] First unseen.* OK [UIDVALIDITY
1602234520] UIDs valid* OK [UIDNEXT 2] Predicted next UID* OK [NOMODSEQ] No
permanent modsequences2 OK [READ-WRITE] Select completed (0.003 + 0.000 + 0.002
secs).2 UID SEARCH HEADER From user* SEARCH 12 OK Search completed (0.002 +
0.000 + 0.001 secs).
Error log:
Oct 09 12:58:22 Panic: imap(user)<31554>: Module context
fts_mailbox_list_module missingOct 09 12:58:22 Error:
imap(user)<31554>: Raw backtrace:
/usr/lib64/dovecot/libdovecot.so.0(backtrace_append+0x42) [0x7fbe88afddf2] ->
/usr/lib64/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7fbe88afdefe] ->
/usr/lib64/dovecot/libdovecot.so.0(+0xec42e) [0x7fbe88b0842e] ->
/usr/lib64/dovecot/libdovecot.so.0(+0xec4d1) [0x7fbe88b084d1] ->
/usr/lib64/dovecot/libdovecot.so.0(i_fatal+0) [0x7fbe88a5f4ea] ->
/usr/lib64/dovecot/lib20_fts_plugin.so(+0x123f7) [0x7fbe8821f3f7] ->
/usr/lib64/dovecot/lib20_fts_plugin.so(+0xe2f4) [0x7fbe8821b2f4] ->
/usr/lib64/dovecot/lib20_fts_plugin.so(fts_search_lookup+0xd4) [0x7fbe8821b7b4]
-> /usr/lib64/dovecot/lib20_fts_plugin.so(+0x11a98) [0x7fbe8821ea98] ->
dovecot/imap(imap_search_start+0x70) [0x55e251f4e620] ->
dovecot/imap(cmd_search+0xd6) [0x55e251f3ea86] ->
dovecot/imap(command_exec+0x64) [0x55e251f46cc4] -> dovecot/imap(+0x1ce4f)
[0x55e251f44e4f] -> dovecot/imap(+0x1ced7) [0x55e251f44ed7] ->
dovecot/imap(client_handle_input+0x205) [0x55e251f45365] ->
dovecot/imap(client_input+0x75) [0x55e251f45925] ->
/usr/lib64/dovecot/libdovecot.so.0(io_loop_call_io+0x65) [0x7fbe88b20b45] ->
/usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x12b)
[0x7fbe88b2249b] ->
/usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run+0x59) [0x7fbe88b20c49]
-> /usr/lib64/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7fbe88b20e88] ->
/usr/lib64/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7fbe88a90393] ->
dovecot/imap(main+0x332) [0x55e251f36f12] ->
/lib64/libc.so.6(__libc_start_main+0xf5) [0x7fbe88670555] ->
dovecot/imap(+0xf115) [0x55e251f37115]Oct 09 12:58:22 Fatal:
imap(user)<31554>: master: service(imap): child 31554 killed
with signal 6 (core dumped)
Dovecot configuration (doveconf -n):# 2.3.11.3 (502c39af9):
/etc/dovecot/dovecot.conf
# OS: Linux 3.10.0-1127.19.1.el7.x86_64 x86_64 CentOS Linux release 7.8.2003
(Core)first_valid_uid = 1000
mail_debug = yesmail_location = maildir:~/Maildir:INDEX=MEMORYmail_plugins =
virtual fts fts_lucenembox_write_locks = fcntlnamespace inbox { inbox = yes
location = prefix = separator = /}namespace virtual { hidden = yes list =
no location = virtual:/etc/dovecot/virtual:INDEX=~/virtual prefix = Search/
separator = / subscriptions = no type = private}passdb { args = scheme=PLAIN
username_format=%u /etc/dovecot/users driver = passwd-file}plugin { fts =
lucene fts_lucene = whitespace_chars=@.}userdb {
args = username_format=%u /etc/dovecot/users driver = passwd-file}
Backtrace:#0 0x7fbe88684387 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1 0x7fbe88685a78 in __GI_abort () at abort.c:90#2 0x7fbe88b083e7 in
default_fatal_finish (status=0, type=) at failures.c:459#3
fatal_handler_real (ctx=, format=,
args=) at failures.c:471#4 0x7fbe88b084d1 in
i_internal_fatal_handler (ctx=, format=,
args=) at failures.c:848#5 0x7fbe88a5f4ea in i_panic
(format=format@entry=0x7fbe88225058 "Module context fts_mailbox_list_module
missing")
Re: Feature request.
Automatic renewal The Ubuntu package for certbot comes pre-configured with systemd timer that will automatically renew existing certificates. What it does not handle however is reloading postfix/dovecot so that they will begin using the new certificates. For that, we need to implement a hook. Certbot has both pre and post hooks that you can use to execute a script prior to and after the renewal process. It also has a renew hook that is run whenever a certificate is successfully renewed. Both the renew hook and post hook are good candidates for our reload script. Each has a downside however. The post hook will be run after every renewal attempt, regardless of if anything was actually renewed or not. This will result in the services being reloaded many times for no reason. The renew hook only runs if a certificate was successfully renewed, but it will be run once for each certificate. This could mean reloading services multiple times if you have multiple certificates. If you only have a single certificate however it'll work great. In my case I only have a single certificate, so the renew hook is what I'm going to use. To setup the hooks a configuration file for certbot needs to be created at /etc/letsencrypt/cli.ini. The configuration file consists of simple name=value pairs where the name is taken from the list of command line parameters. To configure a renew hook, add the following to the configuration file: renew-hook = /root/bin/certbot-renew Next, create the renew hook script at /root/bin/certbot-renew with the following contents: #!/bin/sh systemctl reload postfix systemctl reload dovecot Sent from my iPhone > On Oct 9, 2020, at 04:17, Rogier Wolff wrote: > > Hi, > > I get my Email from my own SMTP server on the internet using > "fetchmail". Some time ago I did the smart thing and configured > dovecot to use SSL and the letsencrypt certificate that automatically > renews. > > Wel. a few days ago my certificate expired and the fetchmail > deamon running in the background had nowhere to complain. So I didn't > notice. > > It turns out that dovecot had been running uninterrupted since august > 13th, the certificate was renewed on september 7th and I suspect it > expired on october 7th. > > So Feature request: check the expiry date on the SSL certificate > as it is being loaded and check for a new certificate if it HAS > expired. > > If you worry about performance, this could be done where: > > TLS handshaking: SSL_accept() failed: error:14094415:SSL > routines:ssl3_read_bytes:sslv3 alert certificate expired: SSL alert number 45 > > is reported. That would mean that ONE client will once get the error > before dovecot fixes it. My personal fix is to restart dovecot once a > week from now on. > > I might be running an older version: > > # 2.2.33.2 (d6601f4ec): /etc/dovecot/dovecot.conf > # Pigeonhole version 0.4.21 (92477967) > # OS: Linux 4.15.0-34-generic x86_64 Ubuntu 18.04.5 LTS > > if it has already been fixed, please accept my apologies. > >Roger. > > -- > ** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** > **Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233** > f equals m times a. When your f is steady, and your m is going down > your a is going up. -- Chris Hadfield about flying up the space shuttle.
Re: Feature request.
On 09/10/2020 14:02, Gerald Galster wrote:
I have to say I'm totally baffled since I do nothing when LetsEncrypt renews
the certificate.
I know the cert has been updated because the mail clients asks me if I trust
the certificate.
If it makes a difference I use the bash LetsEncrypt not the Python code.
I don't like all those dependencies certbot (python) installs, but it works
flawlessly on CentOS.
On CentOS 8 you need to enable the EPEL *and* PowerTools repositories
(/etc/yum/repos.d/...)
I've attached a small perl script that I call via cron 30 minutes after certbot
starts which reloads services if necessary.
Best regards
Gerald
#!/usr/bin/perl
my $reload;
open(FF, "find /etc/letsencrypt/live -mtime -1 -name cert.pem |");
while(){
chomp;
next if !$_;
$reload++;
}
close(FF);
if($reload){
system("/usr/bin/systemctl reload httpd");
system("/usr/bin/systemctl reload postfix");
system("/usr/bin/systemctl reload dovecot");
}
With certbot you can simply put a script in
/etc/letsencrypt/renewal-hooks/deploy/:
# deploy-hook-script.sh
set -e
for domain in $RENEWED_DOMAINS; do
case $domain in
domain.com )
chmod 600 "$RENEWED_LINEAGE/fullchain.pem"
chmod 600 "$RENEWED_LINEAGE/privkey.pem"
/usr/bin/systemctl reload dovecot
/usr/bin/systemctl restart opensmtpd
;;
esac
done
Re: Feature request.
> I have to say I'm totally baffled since I do nothing when LetsEncrypt renews
> the certificate.
>
> I know the cert has been updated because the mail clients asks me if I trust
> the certificate.
>
> If it makes a difference I use the bash LetsEncrypt not the Python code.
I don't like all those dependencies certbot (python) installs, but it works
flawlessly on CentOS.
On CentOS 8 you need to enable the EPEL *and* PowerTools repositories
(/etc/yum/repos.d/...)
I've attached a small perl script that I call via cron 30 minutes after certbot
starts which reloads services if necessary.
Best regards
Gerald
#!/usr/bin/perl
my $reload;
open(FF, "find /etc/letsencrypt/live -mtime -1 -name cert.pem |");
while(){
chomp;
next if !$_;
$reload++;
}
close(FF);
if($reload){
system("/usr/bin/systemctl reload httpd");
system("/usr/bin/systemctl reload postfix");
system("/usr/bin/systemctl reload dovecot");
}
Re: Feature request.
As it turns out my cert was renewed Oct 3. I usually don't reply to these "lists" from my phone since I risk the wrath of people who hate top posting. I usually reply from a Linux desktop, not the phone, where I can bottom post. All that said, my phone mail client asked me if I trusted the cert. It was the latest cert since it matches the date on my website. To be fair, I did a backup of the server on the 4th which involved a reboot, which would have loaded a new cert. But I can't possibly be that fortunate all the time. In need to look at that bash script that renews the cert. Maybe it forces a systemctl reload. I could never get that Python LetsEncrypt code to work on Centos. The LetsEncrypt forum suggested the bash script. https://github.com/acmesh-official/acme.shFrom: r...@mrstuudio.eeSent: October 9, 2020 2:57 AMTo: dovecot@dovecot.orgSubject: Re: Feature request. On 09/10/2020 12:52, lists wrote: I have to say I'm totally baffled since I do nothing when LetsEncrypt renews the certificate. I know the cert has been updated because the mail clients asks me if I trust the certificate. Curious. The mail clients really shouldn't ask anything when encountering a valid certificate. Are you sure the client isn't asking you to trust an expired certificate? Reio
Dovecot 2.3.10-2.3.11.3 pop3/imap login problem after upgrade
Hi, I came across a following issue. After upgrading dovecot from 2.3.10 to 2.3.11.3 pop/imap logins fail. Auth method is plain/login ,with ssl required and shadow passdb driver, runnning on Slackware Linux 14.1. The configuration in both cases is the same, and in the past, after each uprgade i had no problems. I did not come across also of any information if upgrading from 2.3.10 to 2.3.11.3 require any significant change to auth configuration. Dovecot v2.3.10 (0da0eff44) starting up for pop3, imap (core dumps disabled) pop3-login: Login: user=, method=PLAIN, rip=89.78.12.2, lip=192.168.100.30, mpid=8109, TLS, session=<7aCIhC6xzehZTgwC> Dovecot v2.3.11.3 (502c39af9) starting up for pop3, imap (core dumps disabled) pop3-login: Disconnected (tried to use unsupported auth mechanism): user=, method=USER, rip=89.78.12.2, lip=192.168.100.30, TLS, session= I appreciate help if someone knows the cause and solution. Regards
Re: Feature request.
On 09/10/2020 12:52, lists wrote: I have to say I'm totally baffled since I do nothing when LetsEncrypt renews the certificate. I know the cert has been updated because the mail clients asks me if I trust the certificate. Curious. The mail clients really shouldn't ask anything when encountering a valid certificate. Are you sure the client isn't asking you to trust an expired certificate? Reio
Re: Feature request.
I have to say I'm totally baffled since I do nothing when LetsEncrypt renews the certificate. I know the cert has been updated because the mail clients asks me if I trust the certificate. If it makes a difference I use the bash LetsEncrypt not the Python code. Original Message From: r...@mrstuudio.ee Sent: October 9, 2020 1:55 AM To: dovecot@dovecot.org Subject: Re: Feature request. On 09/10/2020 11:50, Plutocrat wrote: > On 09/10/2020 4:16 pm, Rogier Wolff wrote: >> It turns out that dovecot had been running uninterrupted since august >> 13th, the certificate was renewed on september 7th and I suspect it >> expired on october 7th. > I guess you could do a few things yourself to make sure the cert is valid. > Thinking out loud: > > - Blunt instrument approach: Just restart/reload Dovecot once a week via a > cron job. Letsencrypt will renew certs with less than 15 days to go, so once > a week should catch it. If you're using Let's Encrypt, then at least the certbot client has renewal hooks that you can use to run dovecot reload etc. Good luck! Reio
Re: Feature request.
On Fri, Oct 09, 2020 at 11:21:09AM +0300, Aki Tuomi wrote: > > > On 09/10/2020 11:16 Rogier Wolff wrote: > > So Feature request: check the expiry date on the SSL certificate > > as it is being loaded and check for a new certificate if it HAS > > expired. > That is indeed old version, but no, there is no automatic > certificate reloading in Dovecot yet. This has been suggested > before, and we have it in our internal issue tracker, but > unfortunately I can't promise any date when it will be done. Ok. I'm glad it is noted somewhere and that hopefully someday someone will get to it. Once a problem is known the solution is often easy. So for example I spent time figuring out why dovecot was rejecting the fetchmail SSL certificate, while in fact it was the other way around. When my certificate next expires I'll probably NOT find out that my fix works or not. It'll go smoothly and I'll have forgotten about it. So no "date" on it is not a problem for me. I'm happy if my report helps put something on the radar and makes things better over time. On Friday: Marc Roos wrote: > Does a dovecot reload not do that? You mean a reload as opposed to a restart? Maybe. So a restart might be more expensive, but my server is way overpowered and can handle the restart. Roger. -- ** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** **Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
Re: Providers running dovecot?
On Fri, Oct 09, 2020 at 10:15:10AM +0200, Olivier Cailloux wrote: > The real, “final” question I am interested in is, but which might be > slightly off-topic on this list (the reason I asked the other > question), is to find providers that satisfy these two conditions: > a) offer free e-mail accounts > b) implement correctly the IMAP SEARCH feature of RFC 3501. IMO this is the right question to ask, even here. > That is because my client uses the IMAP SEARCH feature, and it is > usually implemented incorrectly (e.g. in GMail or MS Exchange). Probably it would be more informative to describe which features you need that are implemented "incorrectly". Reality check: RFCs are not government-enforced standards. There are many sensible RFCs that never got implemented widely, or nearly at all, are implemented partially, or there are widely deployed not-fully-compliant software systems. If your client software requires a feature that's not widely available, you're just limiting your audience. You may try to find a different way to achieve your goal using the features that are widely implemented. Real, successful software packages very often contain options to do some quirks in order to stay interoperable with existing noncompliant implementations. -- Piotr "Malgond" Auksztulewicz firstn...@lastname.net
Re: Feature request.
On 09/10/2020 11:50, Plutocrat wrote: On 09/10/2020 4:16 pm, Rogier Wolff wrote: It turns out that dovecot had been running uninterrupted since august 13th, the certificate was renewed on september 7th and I suspect it expired on october 7th. I guess you could do a few things yourself to make sure the cert is valid. Thinking out loud: - Blunt instrument approach: Just restart/reload Dovecot once a week via a cron job. Letsencrypt will renew certs with less than 15 days to go, so once a week should catch it. If you're using Let's Encrypt, then at least the certbot client has renewal hooks that you can use to run dovecot reload etc. Good luck! Reio
Re: Feature request.
On 09/10/2020 4:16 pm, Rogier Wolff wrote: > It turns out that dovecot had been running uninterrupted since august > 13th, the certificate was renewed on september 7th and I suspect it > expired on october 7th. I guess you could do a few things yourself to make sure the cert is valid. Thinking out loud: - Blunt instrument approach: Just restart/reload Dovecot once a week via a cron job. Letsencrypt will renew certs with less than 15 days to go, so once a week should catch it. - Check certificate validity with openssl command line client via a script. I wrote one that goes around all the websites under my care and checks. Should be possible to do it for mail servers too? - Check manually with a tool like this https://ssl-tools.net/mailservers/ P.
RE: Feature request.
Does a dovecot reload not do that? For a webserver I just set a flag and a cron job. Whenever I put a new cert, the webserver reloads. -Original Message- To: Rogier Wolff; dovecot@dovecot.org Subject: Re: Feature request. > On 09/10/2020 11:16 Rogier Wolff wrote: > > > Hi, > > I get my Email from my own SMTP server on the internet using > "fetchmail". Some time ago I did the smart thing and configured > dovecot to use SSL and the letsencrypt certificate that automatically > renews. > > Wel. a few days ago my certificate expired and the fetchmail > deamon running in the background had nowhere to complain. So I didn't > notice. > > It turns out that dovecot had been running uninterrupted since august > 13th, the certificate was renewed on september 7th and I suspect it > expired on october 7th. > > So Feature request: check the expiry date on the SSL certificate > as it is being loaded and check for a new certificate if it HAS > expired. > > If you worry about performance, this could be done where: > > TLS handshaking: SSL_accept() failed: error:14094415:SSL > routines:ssl3_read_bytes:sslv3 alert certificate expired: SSL alert > number 45 > > is reported. That would mean that ONE client will once get the error > before dovecot fixes it. My personal fix is to restart dovecot once a > week from now on. > > I might be running an older version: > > # 2.2.33.2 (d6601f4ec): /etc/dovecot/dovecot.conf # Pigeonhole version > 0.4.21 (92477967) # OS: Linux 4.15.0-34-generic x86_64 Ubuntu 18.04.5 > LTS > > if it has already been fixed, please accept my apologies. > > Roger. > That is indeed old version, but no, there is no automatic certificate reloading in Dovecot yet. This has been suggested before, and we have it in our internal issue tracker, but unfortunately I can't promise any date when it will be done. Aki
Re: Feature request.
> On 09/10/2020 11:16 Rogier Wolff wrote: > > > Hi, > > I get my Email from my own SMTP server on the internet using > "fetchmail". Some time ago I did the smart thing and configured > dovecot to use SSL and the letsencrypt certificate that automatically > renews. > > Wel. a few days ago my certificate expired and the fetchmail > deamon running in the background had nowhere to complain. So I didn't > notice. > > It turns out that dovecot had been running uninterrupted since august > 13th, the certificate was renewed on september 7th and I suspect it > expired on october 7th. > > So Feature request: check the expiry date on the SSL certificate > as it is being loaded and check for a new certificate if it HAS > expired. > > If you worry about performance, this could be done where: > > TLS handshaking: SSL_accept() failed: error:14094415:SSL > routines:ssl3_read_bytes:sslv3 alert certificate expired: SSL alert number 45 > > is reported. That would mean that ONE client will once get the error > before dovecot fixes it. My personal fix is to restart dovecot once a > week from now on. > > I might be running an older version: > > # 2.2.33.2 (d6601f4ec): /etc/dovecot/dovecot.conf > # Pigeonhole version 0.4.21 (92477967) > # OS: Linux 4.15.0-34-generic x86_64 Ubuntu 18.04.5 LTS > > if it has already been fixed, please accept my apologies. > > Roger. > That is indeed old version, but no, there is no automatic certificate reloading in Dovecot yet. This has been suggested before, and we have it in our internal issue tracker, but unfortunately I can't promise any date when it will be done. Aki
Feature request.
Hi, I get my Email from my own SMTP server on the internet using "fetchmail". Some time ago I did the smart thing and configured dovecot to use SSL and the letsencrypt certificate that automatically renews. Wel. a few days ago my certificate expired and the fetchmail deamon running in the background had nowhere to complain. So I didn't notice. It turns out that dovecot had been running uninterrupted since august 13th, the certificate was renewed on september 7th and I suspect it expired on october 7th. So Feature request: check the expiry date on the SSL certificate as it is being loaded and check for a new certificate if it HAS expired. If you worry about performance, this could be done where: TLS handshaking: SSL_accept() failed: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired: SSL alert number 45 is reported. That would mean that ONE client will once get the error before dovecot fixes it. My personal fix is to restart dovecot once a week from now on. I might be running an older version: # 2.2.33.2 (d6601f4ec): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.21 (92477967) # OS: Linux 4.15.0-34-generic x86_64 Ubuntu 18.04.5 LTS if it has already been fixed, please accept my apologies. Roger. -- ** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** **Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
Re: Providers running dovecot?
Le jeudi 08 octobre 2020 à 21:41 +0200, Marc Roos a écrit : > There is no such thing as free. If you do not pay anything, you know > you are the product. I do not wish to debate here about whether anything is really free in this world and what this would mean exactly, but I expect people understand what I mean in this context when I refer to a “free e-mail account”. Similarly, if you mean that it is a bad idea on my part to suggest to my users to open a free e-mail account, well, you may be right, but I currently don’t think so, and what I know for sure is that this is a long and complicated debate that I’d rather not have here and now. > >for an e-mail address just to use my software, so I’d recommend > only > a > >provider who gives starter plans for free. (Of course these users > in > >turn would perhaps then upgrade their plan if they want to.) > > I don't think providers would be very willing (understatement) to > install > your software on their platform that services their other clients. > I assume this is server side, since you enquire about dovecot. My software acts as an IMAP client. I do not expect providers to install anything for me, I just want to find a provider that uses dovecot and offers e-mail accounts for free. For example, one answer to my question would be: “GMail offers e-mail accounts for free and uses dovecot”. (This would not be true, as GMail does not use dovecot, but if the statement would be true, it would correctly answer my question.) I would then be able to recommend my users to open an e-mail account at GMail, if they do not have one already, and they would then be able to use my software with their GMail account. > > >So far I didn’t find a service provider providing free e-mail > accounts > >(similar to GMail, Yahoo, …) and using Dovecot, which I find very > >surprising, as I thought some of these big names, or at least some > >smaller ones that I do not know, would use Dovecot. > > > > T-mobile uses dovecot, find t-mobile users ;) My question is really: are there providers out there that satisfy these two conditions: a) offer free e-mail accounts (similar to Yahoo, GMail, and so on) b) use dovecot as their IMAP software. Also, information that would point to a non-existence result would be of interest. For example, an article that indicates which softwares the main providers (that offer e-mail accounts for free) use. The real, “final” question I am interested in is, but which might be slightly off-topic on this list (the reason I asked the other question), is to find providers that satisfy these two conditions: a) offer free e-mail accounts b) implement correctly the IMAP SEARCH feature of RFC 3501. That is because my client uses the IMAP SEARCH feature, and it is usually implemented incorrectly (e.g. in GMail or MS Exchange). -- Olivier
