Re: [feature request] SSL handshake rejection for non-SNI clients

[Aki Tuomi via dovecot]

Hi!

We are indeed listening. And Dovecot actually can check the name on the 
certificate, if you ask it to do so.

https://doc.dovecot.org/settings/core/#core_setting-auth_ssl_username_from_cert

Aki

> On 16/05/2023 14:58 EEST Sean Gallagher  wrote:
> 
>  
> It gets worse! If you request a client certificate, Dovecot will not 
> check the name on the certificate, only that it is signed by a known CA. 
> I raised this issue on this list some time ago and got no response. I'm 
> not sure anyone is listening.
> 
> On 16/05/2023 7:54 pm, Serg via dovecot wrote:
> > I would like to offer to implement a feature to reject SSL handshakes 
> > for a default certificate-key pair for efficiently discarding bot 
> > requests (i.e. such requests that provide invalid/not configured 
> > hostname or do not specify at all, like when doing request to the IP 
> > address directly).
> >
> > Nginx has such feature already implemented as seen here[1], and it 
> > would be beneficial if dovecot would support this too.
> >
> > Currently I am using the following SSL configuration snippet to mimic 
> > such behavior:
> >
> >> ssl_cert =  >> ssl_key =  >>
> >> local_name flopster.at.encryp.ch {     ssl_cert = 
> >>  >>     ssl_key =  >> }
> >
> > But in this case the problem is that the invalid requests (for this 
> > example it is requests that don't have Server Name Indication at all 
> > or mention anything else but not flopster.at.encryp.ch) are still 
> > being replied by Dovecot with a TLS certificate rather than being 
> > simply rejected with a TLSV1_UNRECOGNIZED_NAME error code.
> >
> > [1]: 
> > 
> > ___
> > dovecot mailing list -- dovecot@dovecot.org
> > To unsubscribe send an email to dovecot-le...@dovecot.org
> 
> -- 
> This email has been checked for viruses by AVG antivirus software.
> www.avg.com
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: [feature request] SSL handshake rejection for non-SNI clients

[Sean Gallagher]

It gets worse! If you request a client certificate, Dovecot will not 
check the name on the certificate, only that it is signed by a known CA. 
I raised this issue on this list some time ago and got no response. I'm 
not sure anyone is listening.


On 16/05/2023 7:54 pm, Serg via dovecot wrote:
I would like to offer to implement a feature to reject SSL handshakes 
for a default certificate-key pair for efficiently discarding bot 
requests (i.e. such requests that provide invalid/not configured 
hostname or do not specify at all, like when doing request to the IP 
address directly).


Nginx has such feature already implemented as seen here[1], and it 
would be beneficial if dovecot would support this too.


Currently I am using the following SSL configuration snippet to mimic 
such behavior:



ssl_cert = local_name flopster.at.encryp.ch {     ssl_cert = 

    ssl_key = 

But in this case the problem is that the invalid requests (for this 
example it is requests that don't have Server Name Indication at all 
or mention anything else but not flopster.at.encryp.ch) are still 
being replied by Dovecot with a TLS certificate rather than being 
simply rejected with a TLSV1_UNRECOGNIZED_NAME error code.


[1]: 


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: feature-request: make received-header on submission optional or at least drop the ip in it

[Aki Tuomi]

> On 03/01/2022 17:15 dc...@dvl.werbittewas.de wrote:
> 
>  
> Am 03.01.22 um 15:47 schrieb Michael Peddemors:
> 
> > Using your email system IS the reason, simply make sure that you inform
> 
> no, it's not.
> 
> and:
> 
> > (SLA, Terms and Conditions etc) and it has a valid use, eg for security
> > purposes.
> 
> for security_reasons it's completly ok, to store this information
> *locally* on the server for some time, but not to push this information
> together with date+time towards the world.
> 
> sorry, if you don't have an idea of privacy-needs, you should not post
> about this topic and then say something about "no flames please"...
> 
> > Oh, but no flames please, this is almost getting off topic as it is.
> 
> well, then let's come back to the origin topic.
> 
> There's an need for it (as I noticed meanwhile at least back to 2019:
>  https://dovecot.org/pipermail/dovecot/2019-August/116865.html ) and
> until it breaks no existing thing (which is expected due to *optional*
> settings ), there's no reason to discuss about that need itself.
> 
> ( You won't be forced to enable it for Your mail-server )
> 
> @others: due to the importance of it for us, I'm currently trying to
> implement it, but because that's my first deeper view in dovecots code,
> maybe I'll need some help.
> 
> d.

Hi!

We'll take a look at your patch. Can you please point out to some legal 
information about the Received header's GDPR incompliance, I would be 
interested to see it.

Aki

Re: feature-request: make received-header on submission optional or at least drop the ip in it

[dc-ml]

Am 03.01.22 um 15:47 schrieb Michael Peddemors:

> Using your email system IS the reason, simply make sure that you inform

no, it's not.

and:

> (SLA, Terms and Conditions etc) and it has a valid use, eg for security
> purposes.

for security_reasons it's completly ok, to store this information
*locally* on the server for some time, but not to push this information
together with date+time towards the world.

sorry, if you don't have an idea of privacy-needs, you should not post
about this topic and then say something about "no flames please"...

> Oh, but no flames please, this is almost getting off topic as it is.

well, then let's come back to the origin topic.

There's an need for it (as I noticed meanwhile at least back to 2019:
 https://dovecot.org/pipermail/dovecot/2019-August/116865.html ) and
until it breaks no existing thing (which is expected due to *optional*
settings ), there's no reason to discuss about that need itself.

( You won't be forced to enable it for Your mail-server )

@others: due to the importance of it for us, I'm currently trying to
implement it, but because that's my first deeper view in dovecots code,
maybe I'll need some help.

d.

Re: feature-request: make received-header on submission optional or at least drop the ip in it

[Michael Peddemors]

On 2022-01-01 11:04 a.m., dc...@dvl.werbittewas.de wrote:

because the client-ip is covered by GDPR as personal data and so it
should never shown to others without a certain reason, we want to hide
it, but there's no "submission_add_received_header"-option like for lmtp
and it doesn't seem to be any other option to hide this information.


Using your email system IS the reason, simply make sure that you inform 
customers why this is presented.  The world will thank you ;)


Sorry, but while an IP has been described as personal data in various 
privacy legislation, just like to stop the spreading of misinformation 
that you 'cannot' include that information.


You can include personal information, as long as the person is aware 
(SLA, Terms and Conditions etc) and it has a valid use, eg for security 
purposes.


Oh, but no flames please, this is almost getting off topic as it is.


--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

RE: feature request: maintain folder structure with expunged email

[Marc]

Hi this lazy_expunge is indeed the functionality I am looking for.  First I 
thought I could use the dovecot purge for this (by just not running it). But it 
is just not suited for it. 

I am looking for a way: to allow to recover accidentally deleted emails 
(+folder structure) quickly, without the necessity of restoring them from 
backup. I think it is good to keep such an option.

Does this lazy_expunge take into account the moving of messages between 
namespaces? Currently you have a copy + delete action and these messages I do 
not want to have in the laze_expunge.


> -Original Message-
> Sent: 17 March 2021 14:09
> Cc: dovecot@dovecot.org
> Subject: Re: feature request: maintain folder structure with expunged
> email
> 
> On 17. Mar 2021, at 13.39, Marc mailto:Marc@f1-
> outsourcing.eu> > wrote:
> 
> 
> 
>   Feature request: maintain folder/mailbox structure with expunging.
> 
> 
> You could use lazy_expunge with a namespace. Although it's marked as
> deprecated, so that might go away at some point. There have been some
> thoughts about the ability to remember the original folder also in the
> mailbox-based lazy_expunge folder, but it's not in any near future
> plans.

RE: feature request: prevent linking of email

[Marc]

> 
> diff --git a/src/lib-storage/index/dbox-multi/mdbox-save.c b/src/lib-
> storage/index/dbox-multi/mdbox-save.c
> index ff6e4f77b0..b522951b1d 100644
> --- a/src/lib-storage/index/dbox-multi/mdbox-save.c
> +++ b/src/lib-storage/index/dbox-multi/mdbox-save.c
> @@ -440,7 +440,7 @@ int mdbox_copy(struct mail_save_context *_ctx,
> struct mail *mail)
> ctx->ctx.finished = TRUE;
> 
> if (mail->box->storage != _ctx->transaction->box->storage ||
> -   _ctx->transaction->box->disable_reflink_copy_to)
> +   _ctx->transaction->box->disable_reflink_copy_to || TRUE)
> return mail_storage_copy(_ctx, mail);
> src_mbox = MDBOX_MAILBOX(mail->box);

I think you also have to adapt doveadm force-resync so it convert links to 
copies of old emails.

RE: feature request: prevent linking of email

[Marc]

> 
> mdbox is intended to be high performance mail storage, and this would
> make copying significantly slower.

1. But copying does not happen that often.
2. You already have this copy between namespaces (with different storage)
3. If this really is an issue you could also use a command to schedule the 
copying, first a link, and then run some command like doveadm purge to convert 
the link into a copy.


> If you care more about reliability,
> maybe switch to sdbox or maildir instead?

sdbox and maildir is having that mails are stored as individual files. If you 
use ceph for distributed storage, you will create a considerable storage 
overhead when storing these small files. 
Currently I am using the mdbox_rotate_size = 4M this so it is matching the 
default chunk/stripe size of ceph. 

> It would be easy enough to patch though:
> 
> diff --git a/src/lib-storage/index/dbox-multi/mdbox-save.c b/src/lib-
> storage/index/dbox-multi/mdbox-save.c
> index ff6e4f77b0..b522951b1d 100644
> --- a/src/lib-storage/index/dbox-multi/mdbox-save.c
> +++ b/src/lib-storage/index/dbox-multi/mdbox-save.c
> @@ -440,7 +440,7 @@ int mdbox_copy(struct mail_save_context *_ctx,
> struct mail *mail)
> ctx->ctx.finished = TRUE;
> 
> if (mail->box->storage != _ctx->transaction->box->storage ||
> -   _ctx->transaction->box->disable_reflink_copy_to)
> +   _ctx->transaction->box->disable_reflink_copy_to || TRUE)
> return mail_storage_copy(_ctx, mail);
> src_mbox = MDBOX_MAILBOX(mail->box);

I would offer a config option:

mdbox_message_linking = no (copy message on request)
mdbox_message_linking = delayed (schedule the copying of messages)

:)

Re: feature request: prevent linking of email

[Timo Sirainen]

On 17. Mar 2021, at 13.39, Marc  wrote:
> 
> The reason for copying an email to a different folder is that it is 
> important. You do not want to loose it, and you want to be able to find it 
> there.
> It is wrong to assume that a user will notice that these emails are missing 
> and should look for them elsewhere. 
> Say you have folder for a court case, and you copy emails there relevant for 
> the court case. How can you ever know after a restore that a few email are 
> missing from the folder, and which ones.
> 
> I think it is bad this email is currently 'lost'. I rather have an option in 
> dovecot that disables this hidden 'deduplication' feature. I think this 
> should be the default setting also.
> 
> This current deduplication feature also is hazardous because if this one copy 
> of the email gets corrupted on the storage, you have no copies left. That is 
> exactly the opposite of what user wants to accomplish with creating a copy.
> 
> Feature request: disable this automatic linking of emails between mailboxes.
> Feature request: set this as a default.

mdbox is intended to be high performance mail storage, and this would make 
copying significantly slower. If you care more about reliability, maybe switch 
to sdbox or maildir instead?

It would be easy enough to patch though:

diff --git a/src/lib-storage/index/dbox-multi/mdbox-save.c 
b/src/lib-storage/index/dbox-multi/mdbox-save.c
index ff6e4f77b0..b522951b1d 100644
--- a/src/lib-storage/index/dbox-multi/mdbox-save.c
+++ b/src/lib-storage/index/dbox-multi/mdbox-save.c
@@ -440,7 +440,7 @@ int mdbox_copy(struct mail_save_context *_ctx, struct mail 
*mail)
ctx->ctx.finished = TRUE;

if (mail->box->storage != _ctx->transaction->box->storage ||
-   _ctx->transaction->box->disable_reflink_copy_to)
+   _ctx->transaction->box->disable_reflink_copy_to || TRUE)
return mail_storage_copy(_ctx, mail);
src_mbox = MDBOX_MAILBOX(mail->box);

Re: feature request: maintain folder structure with expunged email

[Timo Sirainen]

On 17. Mar 2021, at 13.39, Marc  wrote:
> 
> Feature request: maintain folder/mailbox structure with expunging.

You could use lazy_expunge with a namespace. Although it's marked as 
deprecated, so that might go away at some point. There have been some thoughts 
about the ability to remember the original folder also in the mailbox-based 
lazy_expunge folder, but it's not in any near future plans.

Re: Feature request.

[Ralph Seichter]

* Rogier Wolff:

> a few days ago my [Let's Encrypt] certificate expired and the
> fetchmail deamon running in the background had nowhere to
> complain.
> [...]
> 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's not something Dovecot needs to worry about. You did not specify
what mechanism you use to update your certificates, but both certbot and
duplicity (likely the most common tools for Linux) support post-update
hooks that let you automatically reload/restart Dovecot whenever a
certificate update occurs.

-Ralph

Re: Feature request.

[Jean-Daniel]

> Le 10 oct. 2020 à 11:38, @lbutlr  a écrit :
> 
> On 09 Oct 2020, at 02:16, 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.
> 
> The ACME protocol that LE uses has a specific feature for specifying a script 
> to run after a certificate updates. One of the common things to do in these 
> scripts is to restart services like apache and dovecot so they see the new 
> certs. Other common actions are copying the certs to specific locations on 
> the system (like, say, into jails) or even to other hardware.
> 
> This is the best, most reliable, and least fiddly solution.
> 


ACME protocol does not care about script run on renew, as it only specifies the 
network exchange between the ACME client and the ACME server. 
Running hook on script renew is the responsibility of each acme client, and so 
is specific to the client you are using.

All clients have there own way to do it:
- certbot.
- acmebot
- acmetool (which may be a good solution for people who don’t like dependencies 
installed by other solutions as this is a standalone binary)
- Kubernetes CertManager.


Just check the doc for the one you are using.

Re: Feature request.

[@lbutlr]

On 09 Oct 2020, at 02:16, 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.

The ACME protocol that LE uses has a specific feature for specifying a script 
to run after a certificate updates. One of the common things to do in these 
scripts is to restart services like apache and dovecot so they see the new 
certs. Other common actions are copying the certs to specific locations on the 
system (like, say, into jails) or even to other hardware.

This is the best, most reliable, and least fiddly solution.



-- 
SHERRI DOES NOT "GOT BACK" Bart chalkboard Ep. AABF07

Re: Feature request.

[Joseph Tam]

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.

[Rogier Wolff]

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.

[infoomatic]

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: Feature request.

[David Morsberger]

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.

[Reio Remma]

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.

[Gerald Galster]

> 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.

[lists]

  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

  


  

  

Re: Feature request.

[Reio Remma]

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.

[lists]

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.

[Rogier Wolff]

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: Feature request.

[Reio Remma]

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.

[Plutocrat]

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.

[Marc Roos]

 
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.

[Aki Tuomi]

> 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 for setting alternative pidfile

[Bjoern Jacke]

On 12.02.20 17:32, Aki Tuomi wrote:
> You can use base_dir to specify an instance directory where files are stored 
> under.

that works well, thanks!

Björn

Re: feature request for setting alternative pidfile

[Aki Tuomi]

> On 12/02/2020 17:43 Bjoern Jacke  wrote:
> 
>  
> Hi,
> 
> because of an unsupported combination of configuration parameters for
> different dovecot services I looked into setting up two dovecot
> instances with different configurations on the same host. It looks like
> running two different dovecot instances on the same host is not easily
> possible because the pidfile seems to be hard-coded and there is no way
> to tell dovecot to use a different one, right? It would be great if this
> could be made customizable.
> 
> Björn

You can use base_dir to specify an instance directory where files are stored 
under.

Aki

Re: Feature request - blacklistd interaction

[Lefteris Tsintjelis via dovecot]

On 4/5/2019 21:02, Aki Tuomi via dovecot wrote:



On 4 May 2019 20:55 Lefteris Tsintjelis via dovecot  wrote:

  
Would be really really REALLY nice to have dovecot interact directly

with blacklistd! Makes a huge difference on busy systems and beats log
parsing by far.

Thank you


Dovecot supports JSON based weakforce protocol. If you can make adaptor for 
that, then you can make it interact directly.

See https://wiki.dovecot.org/Authentication/Policy

Aki


Make an adapter in order to work with another adapter (blacklistd) in 
order to trigger firewall rules would only make things more complex. 
Keeping things simple is best.

Re: Feature request - blacklistd interaction

[Aki Tuomi via dovecot]

> On 4 May 2019 20:55 Lefteris Tsintjelis via dovecot  
> wrote:
> 
>  
> Would be really really REALLY nice to have dovecot interact directly 
> with blacklistd! Makes a huge difference on busy systems and beats log 
> parsing by far.
> 
> Thank you

Dovecot supports JSON based weakforce protocol. If you can make adaptor for 
that, then you can make it interact directly.

See https://wiki.dovecot.org/Authentication/Policy

Aki

Re: Feature request: exclude IP/network in allow_nets extra field

[A. Schulze via dovecot]

Am 30.04.19 um 03:56 schrieb Zhang Huangbin via dovecot:
> Dear all,
> 
> We use `allow_nets`[1] to restrict login clients, it works fine.
> Recently we need to allow some users to login from everywhere except some 
> IP/networks, how can we accomplish this with "allow_nets"?
> 
> Tried allow_nets="!a.b.c.d", but Dovecot reports error "allow_nets: Invalid 
> network '!a.b.c.d'".
> 
> Can we have this feature?
> 
> i guess it should be done in function "auth_request_validate_networks"[2] in 
> file src/auth/auth-request.c.

I had a similar problem years ago. Usually on set defaults in a configuration 
and overwrite per userdb entry
In my case the userdb was a ldap backend. I liked to limit specific users via 
allow_nets and deny all other.
So I wrote a simple patch for src/auth/auth-request.c to set defaults in case 
my ldap userdb do not return any overwriting.
Patch attached...

Andreas
Description: additional defaults for allow_nets
Author: A. Schulze
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: dovecot-2.3.6/src/auth/auth-request.c
===
--- dovecot-2.3.6.orig/src/auth/auth-request.c
+++ dovecot-2.3.6/src/auth/auth-request.c
@@ -1775,6 +1775,16 @@ auth_request_validate_networks(struct au
 	unsigned int bits;
 	bool found = FALSE;
 
+	if (strcmp(networks, "ALL") == 0) {
+		auth_request_log_debug(request, "auth", "allow_nets: found 'ALL'");
+		request->failed = FALSE;
+		return;
+	}
+	if (strcmp(networks, "NONE") == 0) {
+		auth_request_log_debug(request, "auth", "allow_nets: found 'NONE'");
+		request->failed = TRUE;
+		return;
+	}
 	for (net = t_strsplit_spaces(networks, ", "); *net != NULL; net++) {
 		auth_request_log_debug(request, AUTH_SUBSYS_DB,
 			"%s: Matching for network %s", name, *net);

Re: Feature request: exclude IP/network in allow_nets extra field

[Zhang Huangbin via dovecot]

> On Apr 30, 2019, at 10:37 PM, andre via dovecot  wrote:
> 
> You can easily do this without a new feature in Dovecot.
> 
> - Create a post login script, for instance, in bash.
> - install grepcidr on your server.
> 
> Your post login script can use grepcidr to check for white or black list.
> 
> https://wiki.dovecot.org/PostLoginScripting

Dear Andre,

Thank you very much for the input.

Post login script should work as you suggested, but consider Dovecot already 
supports "allow_nets=a.b.c.d", we just need a mark like "!" to exclude some 
IP/networks, this might be the best and most elegant solution (if it can be 
implemented, of course), because we need only one userdb/passdb for all users, 
just different "allow_nets" for access control. Not one userdb/passdb for one 
each access policy.

Re: Feature request: exclude IP/network in allow_nets extra field

[Zhang Huangbin via dovecot]

> On Apr 30, 2019, at 2:35 PM, Sami Ketola via dovecot  
> wrote:
> 
> Just create another passdb for these premium users before the actual passdb 
> and add skip = authenticated to the actual passdb.

Dear Sami,

Thank you for the suggestion.

Adding more passdb is not ideal at all, if we have more access policies, we 
don't want to add more and more userdb/passdb.
Dovecot already supports syntax "allow_nets=a.b.c.d", we just need something 
like "!" mark to exclude some IP/networks.

Re: Feature request: exclude IP/network in allow_nets extra field

[Zhang Huangbin via dovecot]

> On Apr 30, 2019, at 2:32 PM, Malcolm via dovecot  wrote:
> 
> On 4/29/2019 11:20 PM, Zhang Huangbin via dovecot wrote:
>> I understand what "allow" means. But it will be very handy to support 
>> something like "!a.b.c.d" to allow all but just exclude few
>> IPs/networks. Isn't it? :)
> I'm not sure why:
> 
> iptables -A INPUT -p tcp --match multiport --syn ! -s a.b.c.d/netmask \
> --dports 110,143,993,995 -j REJECT

Dear Malcolm,

Thanks for your reply.
As mentioned earlier, this per-user access control, not for all users. This 
firewall rule blocks all users, not just few users.

Re: Re: Feature request: exclude IP/network in allow_nets extra field

[andre via dovecot]

Sorry for the top posting, I have not setup my new phone yet.

Here the script sample: 
https://github.com/progmaticltd/homebox/blob/dev/install/playbooks/roles/dovecot/files/access-check-whitelist.sh

André.

Tue Apr 30 15:33:51 GMT+01:00 2019 andre :

>
> Hello, Zhang.
>
> You can easily do this without a new feature in Dovecot.
>
> - Create a post login script, for instance, in bash.
>  - install grepcidr on your server.
>
> Your post login script can use grepcidr to check for white or black list.
>
> https://wiki.dovecot.org/PostLoginScripting
>
> I have implemented this myself on a small open source project, I can send you 
> the links of you want.
>
> André.
>
> Tue Apr 30 02:57:18 GMT+01:00 2019 Zhang Huangbin via dovecot 
> :
>
>> Dear all,
>>
>> We use `allow_nets`[1] to restrict login clients, it works fine.
>> Recently we need to allow some users to login from everywhere except some 
>> IP/networks, how can we accomplish this with "allow_nets"?
>>
>> Tried allow_nets="!a.b.c.d", but Dovecot reports error "allow_nets: Invalid 
>> network '!a.b.c.d'".
>>
>> Can we have this feature?
>>
>> i guess it should be done in function "auth_request_validate_networks"[2] in 
>> file src/auth/auth-request.c.
>>
>> [1] allow_nets: 
>> https://wiki.dovecot.org/PasswordDatabase/ExtraFields/AllowNets
>> [2] 
>> https://github.com/dovecot/core/blob/fbc3ccc4a9a02b82073585a33254eacedc6a9950/src/auth/auth-request.c#L1990
>

Re: Feature request: exclude IP/network in allow_nets extra field

[andre via dovecot]

Hello, Zhang.

You can easily do this without a new feature in Dovecot.

- Create a post login script, for instance, in bash.
 - install grepcidr on your server.

Your post login script can use grepcidr to check for white or black list.

https://wiki.dovecot.org/PostLoginScripting

I have implemented this myself on a small open source project, I can send you 
the links of you want.

André.

Tue Apr 30 02:57:18 GMT+01:00 2019 Zhang Huangbin via dovecot 
:

> Dear all,
>
> We use `allow_nets`[1] to restrict login clients, it works fine.
> Recently we need to allow some users to login from everywhere except some 
> IP/networks, how can we accomplish this with "allow_nets"?
>
> Tried allow_nets="!a.b.c.d", but Dovecot reports error "allow_nets: Invalid 
> network '!a.b.c.d'".
>
> Can we have this feature?
>
> i guess it should be done in function "auth_request_validate_networks"[2] in 
> file src/auth/auth-request.c.
>
> [1] allow_nets: 
> https://wiki.dovecot.org/PasswordDatabase/ExtraFields/AllowNets
> [2] 
> https://github.com/dovecot/core/blob/fbc3ccc4a9a02b82073585a33254eacedc6a9950/src/auth/auth-request.c#L1990

Re: Feature request: exclude IP/network in allow_nets extra field

[@lbutlr via dovecot]

On 30 Apr 2019, at 00:20, Zhang Huangbin via dovecot  
wrote:
> On Apr 30, 2019, at 11:21 AM, @lbutlr via dovecot  wrote:
>> 
>> On 29 Apr 2019, at 19:56, Zhang Huangbin via dovecot  
>> wrote:
>>> Recently we need to allow some users to login from everywhere except some 
>>> IP/networks,
>> 
>> Can you use firewall rules for this?
> 
> I suppose not. We don't restrict ALL users this way, just few of them.

This iOS sounding odder and odder.

> And the client IP addresses may change frequently, not static IPs.

And? How is that an issue? Either way you are going to have to change a 
configuration. At least with a fireball, you don't have to reload dovecot each 
time.

>>> how can we accomplish this with "allow_nets"?
>> 
>> Allow_nets specifies allowed networks. Doesn't say anything else about any 
>> other use.
>> 
>> "The allow_nets field is a comma separated list of IP addresses and/or 
>> networks where the user is allowed to log in from."
> 
> I understand what "allow" means. But it will be very handy to support 
> something like "!a.b.c.d" to allow all but just exclude few IPs/networks. 
> Isn't it? :)

I cannot imagine a case where I would find this useful, no.


-- 
"You never really understand a person until you see things from his
point of view, until you climb inside of his skin and walk around in
it."

Re: Feature request: exclude IP/network in allow_nets extra field

[Sami Ketola via dovecot]

> On 30 Apr 2019, at 4.56, Zhang Huangbin via dovecot  
> wrote:
> 
> Dear all,
> 
> We use `allow_nets`[1] to restrict login clients, it works fine.
> Recently we need to allow some users to login from everywhere except some 
> IP/networks, how can we accomplish this with "allow_nets"?
> 
> Tried allow_nets="!a.b.c.d", but Dovecot reports error "allow_nets: Invalid 
> network '!a.b.c.d'".
> 
> Can we have this feature?


Just create another passdb for these premium users before the actual passdb and 
add skip = authenticated to the actual passdb.

Sami

Re: Feature request: exclude IP/network in allow_nets extra field

[Malcolm via dovecot]

On 4/29/2019 11:20 PM, Zhang Huangbin via dovecot wrote:
I understand what "allow" means. But it will be very handy to 
support something like "!a.b.c.d" to allow all but just exclude few

IPs/networks. Isn't it? :)

I'm not sure why:

iptables -A INPUT -p tcp --match multiport --syn ! -s a.b.c.d/netmask \
--dports 110,143,993,995 -j REJECT

doesn't do what you want.

Or do you want some kind of "friendlier" message to be provided once the 
user(s) login from the blocked IP#s to tell them why they can't login?


=M=

Re: Feature request: exclude IP/network in allow_nets extra field

[Zhang Huangbin via dovecot]

> On Apr 30, 2019, at 11:21 AM, @lbutlr via dovecot  wrote:
> 
> On 29 Apr 2019, at 19:56, Zhang Huangbin via dovecot  
> wrote:
>> Recently we need to allow some users to login from everywhere except some 
>> IP/networks,
> 
> Can you use firewall rules for this?

I suppose not. We don't restrict ALL users this way, just few of them.
And the client IP addresses may change frequently, not static IPs.

>> how can we accomplish this with "allow_nets"?
> 
> Allow_nets specifies allowed networks. Doesn't say anything else about any 
> other use.
> 
> "The allow_nets field is a comma separated list of IP addresses and/or 
> networks where the user is allowed to log in from."

I understand what "allow" means. But it will be very handy to support something 
like "!a.b.c.d" to allow all but just exclude few IPs/networks. Isn't it? :)

Re: Feature request: exclude IP/network in allow_nets extra field

[@lbutlr via dovecot]

On 29 Apr 2019, at 19:56, Zhang Huangbin via dovecot  
wrote:
> Recently we need to allow some users to login from everywhere except some 
> IP/networks,

Can you use firewall rules for this?

> how can we accomplish this with "allow_nets"?

Allow_nets specifies allowed networks. Doesn't say anything else about any 
other use.

"The allow_nets field is a comma separated list of IP addresses and/or networks 
where the user is allowed to log in from."

Re: Feature request: client bind address for replication

[Stephan Bosch]

Hi John,

Op 04/01/2019 om 16:25 schreef John Fawcett:

Hi

would it be possible to consider a new parameter for replication:
doveadm_local_ip which allows the source ip address to be set when
connection to a remote dovecot for replication?

It could be useful when the network interface has multiple ips and a
specific one is used for mail services. See attached proposal. I tested
against 2.2.36 only. It applies correctly against 2.3.4 with a warning,.


I am not sure whether this can be added (soon or at all), but it is now 
tracked internally as DOP-869 so we don't forget.


Regards,

Stephan.

Re: Feature request SCRAM-SHA-256

[Stephan Bosch]

Op 07/01/2019 om 20:31 schreef Stephan Bosch:


Op 16/12/2018 om 10:06 schreef Tributh via dovecot:


Am 16.12.18 um 09:42 schrieb Aki Tuomi:
On 16 December 2018 at 10:27 Tributh via dovecot 
 wrote:



Hi,
is that here the right place to make feature requests?

dovecot supports as authentication mechanism
SCRAM-SHA-1 from RFC 5802
which was updated to
SCRAM-SHA-256 in RFC 7677

Can SCRAM-SHA-256 be added to the authentication mechanisms?

I would not like to request, that SCRAM-SHA-1 will be exchanged by
SCRAM-SHA-256, since several applications only support SCRAM-SHA-1

Regards

Torsten

Hi!

Adding this is possible, it can even be done as a separate plugin. 
But I have to ask, why? Do you actually have clients that support this?


Aki


Hi Aki,
let me first answer the second question.
Sadly I have no client which supports it, yet.
Here we have a chicken or the egg causality dilemma.
There was some communication with mail-client developers which stated
that they would start developing it, when they have a publicly usable
server to test against.
Now I hope that the most common IMAP server could be the one, which
gives this possibility.
Sadly, most communication is not publicly available.

In the past CRAM-MD5 was very popular. When the insecurity came out,
everything just shifted to TLS, but that prevented not from sending a
plain password now. If a malicious actor is able to change DNS/TLS
endpoints, he will receive the plain passwords immediately.
I am not the expert in explaining how such an actor could do this. I
just wanted to have possibilities for everybody to prevent this possible
exposure of a plain password, which could than easily used abusively.

I just hope for better security in the future.



I looked a this a bit and since it is basically only a matter of 
replacing the hash algorithm, I created a quick implementation (after 
some refactoring): 
https://github.com/stephanbosch/dovecot-core/commits/auth-scram-sha-256


However, since there is no client that actually supports this, I 
cannot test this myself. I've briefly tested that the old SHA-1 still 
works (using mpop) and that the server properly announces the new 
mechanism when enabled, but that is it. It is based on the master 
branch. Configuration is identical to SCRAM-SHA-1, apart from the 
mechanism (and password scheme) name of course.


Don't expect this to be released or even merged to the master branch 
any time soon: this is likely currently very low on our priority list. 
But, at least you can run your own server with SCRAM-SHA-256 support 
(and so can client developers).  Maybe if this gets endorsed and 
supported by clients and gets some testing in the field, we can speed 
it along a bit, but that is not something I can promise.


So, I hatched a chick for you. I hope you can make it lay a few eggs 
in the future...


Tracked internally as DOP-840.

Regards,

Stephan.

Re: Feature request SCRAM-SHA-256

[Stephan Bosch]

Hi,

Op 13/01/2019 om 17:48 schreef Tributh via dovecot:

Hi,
sorry for my late reply. Was too busy during the week.
Thank you for your patches. I hope I will be able with them to get now
some client support for SCRAM-SHA-256. Will report how I succeed in the
future.


I managed to test it successfully using MailKit: 
https://github.com/jstedfast/MailKit


I used the IMAP demo in samples/ImapClientDemo. I limited the available 
mechanisms presented by the server to SCRAM-SHA-256 exclusively, so the 
demo needs no modification.


So, from our end it seems to work fine.

Regards,

Stephan.

Re: Re: Feature request SCRAM-SHA-256

[Tributh via dovecot]

Hi,
sorry for my late reply. Was too busy during the week.
Thank you for your patches. I hope I will be able with them to get now
some client support for SCRAM-SHA-256. Will report how I succeed in the
future.

Regards,

Torsten


On 07.01.19 20:31, Stephan Bosch wrote:
> 
> Op 16/12/2018 om 10:06 schreef Tributh via dovecot:
>>
>> Am 16.12.18 um 09:42 schrieb Aki Tuomi:
 On 16 December 2018 at 10:27 Tributh via dovecot
  wrote:


 Hi,
 is that here the right place to make feature requests?

 dovecot supports as authentication mechanism
 SCRAM-SHA-1 from RFC 5802
 which was updated to
 SCRAM-SHA-256 in RFC 7677

 Can SCRAM-SHA-256 be added to the authentication mechanisms?

 I would not like to request, that SCRAM-SHA-1 will be exchanged by
 SCRAM-SHA-256, since several applications only support SCRAM-SHA-1

 Regards

 Torsten
>>> Hi!
>>>
>>> Adding this is possible, it can even be done as a separate plugin.
>>> But I have to ask, why? Do you actually have clients that support this?
>>>
>>> Aki
>>>
>> Hi Aki,
>> let me first answer the second question.
>> Sadly I have no client which supports it, yet.
>> Here we have a chicken or the egg causality dilemma.
>> There was some communication with mail-client developers which stated
>> that they would start developing it, when they have a publicly usable
>> server to test against.
>> Now I hope that the most common IMAP server could be the one, which
>> gives this possibility.
>> Sadly, most communication is not publicly available.
>>
>> In the past CRAM-MD5 was very popular. When the insecurity came out,
>> everything just shifted to TLS, but that prevented not from sending a
>> plain password now. If a malicious actor is able to change DNS/TLS
>> endpoints, he will receive the plain passwords immediately.
>> I am not the expert in explaining how such an actor could do this. I
>> just wanted to have possibilities for everybody to prevent this possible
>> exposure of a plain password, which could than easily used abusively.
>>
>> I just hope for better security in the future.
> 
> 
> I looked a this a bit and since it is basically only a matter of
> replacing the hash algorithm, I created a quick implementation (after
> some refactoring):
> https://github.com/stephanbosch/dovecot-core/commits/auth-scram-sha-256
> 
> However, since there is no client that actually supports this, I cannot
> test this myself. I've briefly tested that the old SHA-1 still works
> (using mpop) and that the server properly announces the new mechanism
> when enabled, but that is it. It is based on the master branch.
> Configuration is identical to SCRAM-SHA-1, apart from the mechanism (and
> password scheme) name of course.
> 
> Don't expect this to be released or even merged to the master branch any
> time soon: this is likely currently very low on our priority list. But,
> at least you can run your own server with SCRAM-SHA-256 support (and so
> can client developers).  Maybe if this gets endorsed and supported by
> clients and gets some testing in the field, we can speed it along a bit,
> but that is not something I can promise.
> 
> So, I hatched a chick for you. I hope you can make it lay a few eggs in
> the future...
> 
> Regards,
> 
> Stephan.
> 
> 

Re: Feature request SCRAM-SHA-256

[Stephan Bosch]

Op 16/12/2018 om 10:06 schreef Tributh via dovecot:


Am 16.12.18 um 09:42 schrieb Aki Tuomi:

On 16 December 2018 at 10:27 Tributh via dovecot  wrote:


Hi,
is that here the right place to make feature requests?

dovecot supports as authentication mechanism
SCRAM-SHA-1 from RFC 5802
which was updated to
SCRAM-SHA-256 in RFC 7677

Can SCRAM-SHA-256 be added to the authentication mechanisms?

I would not like to request, that SCRAM-SHA-1 will be exchanged by
SCRAM-SHA-256, since several applications only support SCRAM-SHA-1

Regards

Torsten

Hi!

Adding this is possible, it can even be done as a separate plugin. But I have 
to ask, why? Do you actually have clients that support this?

Aki


Hi Aki,
let me first answer the second question.
Sadly I have no client which supports it, yet.
Here we have a chicken or the egg causality dilemma.
There was some communication with mail-client developers which stated
that they would start developing it, when they have a publicly usable
server to test against.
Now I hope that the most common IMAP server could be the one, which
gives this possibility.
Sadly, most communication is not publicly available.

In the past CRAM-MD5 was very popular. When the insecurity came out,
everything just shifted to TLS, but that prevented not from sending a
plain password now. If a malicious actor is able to change DNS/TLS
endpoints, he will receive the plain passwords immediately.
I am not the expert in explaining how such an actor could do this. I
just wanted to have possibilities for everybody to prevent this possible
exposure of a plain password, which could than easily used abusively.

I just hope for better security in the future.



I looked a this a bit and since it is basically only a matter of 
replacing the hash algorithm, I created a quick implementation (after 
some refactoring): 
https://github.com/stephanbosch/dovecot-core/commits/auth-scram-sha-256


However, since there is no client that actually supports this, I cannot 
test this myself. I've briefly tested that the old SHA-1 still works 
(using mpop) and that the server properly announces the new mechanism 
when enabled, but that is it. It is based on the master branch. 
Configuration is identical to SCRAM-SHA-1, apart from the mechanism (and 
password scheme) name of course.


Don't expect this to be released or even merged to the master branch any 
time soon: this is likely currently very low on our priority list. But, 
at least you can run your own server with SCRAM-SHA-256 support (and so 
can client developers).  Maybe if this gets endorsed and supported by 
clients and gets some testing in the field, we can speed it along a bit, 
but that is not something I can promise.


So, I hatched a chick for you. I hope you can make it lay a few eggs in 
the future...


Regards,

Stephan.

Re: Feature request SCRAM-SHA-256

[Aki Tuomi]

> On 16 December 2018 at 11:06 Tributh  wrote:
> 
> 
> 
> 
> Am 16.12.18 um 09:42 schrieb Aki Tuomi:
> > 
> >> On 16 December 2018 at 10:27 Tributh via dovecot  
> >> wrote:
> >>
> >>
> >> Hi,
> >> is that here the right place to make feature requests?
> >>
> >> dovecot supports as authentication mechanism
> >> SCRAM-SHA-1 from RFC 5802
> >> which was updated to
> >> SCRAM-SHA-256 in RFC 7677
> >>
> >> Can SCRAM-SHA-256 be added to the authentication mechanisms?
> >>
> >> I would not like to request, that SCRAM-SHA-1 will be exchanged by
> >> SCRAM-SHA-256, since several applications only support SCRAM-SHA-1
> >>
> >> Regards
> >>
> >> Torsten
> > 
> > Hi!
> > 
> > Adding this is possible, it can even be done as a separate plugin. But I 
> > have to ask, why? Do you actually have clients that support this?
> > 
> > Aki
> > 
> Hi Aki,
> let me first answer the second question.
> Sadly I have no client which supports it, yet.
> Here we have a chicken or the egg causality dilemma.
> There was some communication with mail-client developers which stated
> that they would start developing it, when they have a publicly usable
> server to test against.
> Now I hope that the most common IMAP server could be the one, which
> gives this possibility.
> Sadly, most communication is not publicly available.
> 
> In the past CRAM-MD5 was very popular. When the insecurity came out,
> everything just shifted to TLS, but that prevented not from sending a
> plain password now. If a malicious actor is able to change DNS/TLS
> endpoints, he will receive the plain passwords immediately.
> I am not the expert in explaining how such an actor could do this. I
> just wanted to have possibilities for everybody to prevent this possible
> exposure of a plain password, which could than easily used abusively.
> 
> I just hope for better security in the future.
> 
> Regards Torsten
> 
>

We'll see if this could be added.

Aki

Re: Feature request SCRAM-SHA-256

[Tributh via dovecot]

Am 16.12.18 um 09:42 schrieb Aki Tuomi:
> 
>> On 16 December 2018 at 10:27 Tributh via dovecot  wrote:
>>
>>
>> Hi,
>> is that here the right place to make feature requests?
>>
>> dovecot supports as authentication mechanism
>> SCRAM-SHA-1 from RFC 5802
>> which was updated to
>> SCRAM-SHA-256 in RFC 7677
>>
>> Can SCRAM-SHA-256 be added to the authentication mechanisms?
>>
>> I would not like to request, that SCRAM-SHA-1 will be exchanged by
>> SCRAM-SHA-256, since several applications only support SCRAM-SHA-1
>>
>> Regards
>>
>> Torsten
> 
> Hi!
> 
> Adding this is possible, it can even be done as a separate plugin. But I have 
> to ask, why? Do you actually have clients that support this?
> 
> Aki
> 
Hi Aki,
let me first answer the second question.
Sadly I have no client which supports it, yet.
Here we have a chicken or the egg causality dilemma.
There was some communication with mail-client developers which stated
that they would start developing it, when they have a publicly usable
server to test against.
Now I hope that the most common IMAP server could be the one, which
gives this possibility.
Sadly, most communication is not publicly available.

In the past CRAM-MD5 was very popular. When the insecurity came out,
everything just shifted to TLS, but that prevented not from sending a
plain password now. If a malicious actor is able to change DNS/TLS
endpoints, he will receive the plain passwords immediately.
I am not the expert in explaining how such an actor could do this. I
just wanted to have possibilities for everybody to prevent this possible
exposure of a plain password, which could than easily used abusively.

I just hope for better security in the future.

Regards Torsten

Re: Feature request SCRAM-SHA-256

[Aki Tuomi]

> On 16 December 2018 at 10:27 Tributh via dovecot  wrote:
> 
> 
> Hi,
> is that here the right place to make feature requests?
> 
> dovecot supports as authentication mechanism
> SCRAM-SHA-1 from RFC 5802
> which was updated to
> SCRAM-SHA-256 in RFC 7677
> 
> Can SCRAM-SHA-256 be added to the authentication mechanisms?
> 
> I would not like to request, that SCRAM-SHA-1 will be exchanged by
> SCRAM-SHA-256, since several applications only support SCRAM-SHA-1
> 
> Regards
> 
> Torsten

Hi!

Adding this is possible, it can even be done as a separate plugin. But I have 
to ask, why? Do you actually have clients that support this?

Aki

Re: Feature Request - Director Balance

[Webert de Souza Lima]

Shrinking director_user_expire might be a workaround but not as good as a
solution, as also the user can end up mapped to the same server again.
Director flush is both manual and aggressive, so not a good solution too.

The possibility to move users between backends without killing existing
connections is a good solution, yes! It can be scripted. =]

What I suggested was more automated, but that can be left for a future
future. If you have a command to be manually issued like:  "doveadm
director rebalance" it would be great.

Thanks for your feedback.

Att,

Webert de Souza Lima
MAV Tecnologia.


On Fri, Apr 21, 2017 at 4:52 AM, Timo Sirainen  wrote:

> On 20 Apr 2017, at 17.35, Webert de Souza Lima 
> wrote:
> >
> > Hi,
> >
> > often I run into the situation where a dovecot server goes down for
> > maintenance, and all users get concentrated in the remaining dovecot
> server
> > (considering I have 2 dovecot servers only).
> >
> > When that dovecot server comes back online, director server will send new
> > users to it, but the dovecot server that was up all the time will still
> > have tons of clients mapped to it.
> >
> > I suggest the director servers to always try to balance load between
> > servers, in the way:
> >
> > - if a server has several more connections than other, mark it to
> > re-balance
> > - when a user connected to this loaded server disconnects, map it to
> > another server (that is per definition not the same server) immediately.
> >
> > that way it would gracefully re-balance, not killing existing
> connections,
> > just waiting for them to finish.
>
> You could effectively do this by shrinking the director_user_expire time.
> But if it's too low, it causes director to be a bit more inefficient when
> assigning users to backends. Also if backends are doing any background work
> (e.g. full text search indexing) director might move the user away too
> early. But setting it to e.g. 5 minutes would likely help a lot.
>
> There's of course also the doveadm director flush, which can be used to
> move users between backends, but that requires killing the connections for
> now. I've some future plans to make it possible to move connections between
> backends without disconnecting the IMAP client.
>

Re: Feature Request - Director Balance

[Timo Sirainen]

On 20 Apr 2017, at 17.35, Webert de Souza Lima  wrote:
> 
> Hi,
> 
> often I run into the situation where a dovecot server goes down for
> maintenance, and all users get concentrated in the remaining dovecot server
> (considering I have 2 dovecot servers only).
> 
> When that dovecot server comes back online, director server will send new
> users to it, but the dovecot server that was up all the time will still
> have tons of clients mapped to it.
> 
> I suggest the director servers to always try to balance load between
> servers, in the way:
> 
> - if a server has several more connections than other, mark it to
> re-balance
> - when a user connected to this loaded server disconnects, map it to
> another server (that is per definition not the same server) immediately.
> 
> that way it would gracefully re-balance, not killing existing connections,
> just waiting for them to finish.

You could effectively do this by shrinking the director_user_expire time. But 
if it's too low, it causes director to be a bit more inefficient when assigning 
users to backends. Also if backends are doing any background work (e.g. full 
text search indexing) director might move the user away too early. But setting 
it to e.g. 5 minutes would likely help a lot.

There's of course also the doveadm director flush, which can be used to move 
users between backends, but that requires killing the connections for now. I've 
some future plans to make it possible to move connections between backends 
without disconnecting the IMAP client.

Re: Feature Request

[Timo Sirainen]

On 05 Jul 2016, at 00:39, Doug Hardie  wrote:
> 
> I would like to request an additional optional argument for queue-id to 
> dovecot-lda.  The intended use for this argument is to include in the 
> logging.  From what I can tell, the queue-id size is not consistent between 
> the various MTAs and so would need to be allocated dynamically when read 
> during initialization.  
> 
> This element in the log messages would make it easier to find the trace of a 
> received email.  Generally I can easily get the queue-id generated by postfix 
> (or sendmail - I use both).  One grep would then give me the whole picture 
> rather than having to dig out the message-id and doing a secondary grep to 
> obtain the lda log messages.

It wouldn't work with LMTP though, which is nowadays the preferred method of 
delivering mails to Dovecot. So I'd rather not add features that didn't work 
with LMTP.

> I find it interesting that every submission to this list results in a quick 
> response that says moderation is required since I "am not a member". However, 
> I am a member...

You seem to be a member. I don't see anything in logs about you being moderated 
though..

Re: [Feature Request] doveadm option to return number of messages acted upon

[A. Schulze]

Haravikk:

So I have a script for handling my specific archive and expunge  
needs, but it’d be nice to be able to track how many messages are  
being affected.


Currently I’m doing it by firing the same search queries into  
doveadm search and counting the lines of the result with wc -l, but  
that’s not a very pretty solution. While I’m mostly doing it out of  
interest on a personal server, I can’t imagine it’s a very scalable  
way to do it if you wanted to gather some kind of metrics for example.


What I think would make sense would be for relevant doveadm commands  
such as move, expunge (probably purge too) and others I haven’t  
thought of to have a new option that, if enabled, will cause the  
command to output the number of messages affected as the final line  
of output (most of these commands don’t have any output anyway). A  
doveadm count command could also be a convenient, more efficient,  
alternative to doveadm search | wc -l.


+1
statistics are always nice

Andreas