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

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

[Serg via dovecot]

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

Feature Request: login_trusted_networks to take FQDN

[Sean Gallagher]

In a previous post to this list I described a problem I was having 
validating client certificates on inet_listener lmtp connections.


Subject: "Please Help: Dovecot ssl_ca selection based on remote IP 
address filtering not working."


The problem there was that Dovecot does not "inspect" the subject name 
on the client certificate on LMTP connections. As such Any valid 
certificate will pass. In this context "valid" means the same as OpenSSL 
SSL_set_verify( ,SSL_VERIFY_PEER, ). I.e. the certificate chain is well 
formed and can be traced back to a trusted root. It does not say 
anything about the peer's identity.


I propose here, that the "login_trusted_networks" setting be allowed to 
take a domain name - possibly with wildcards. Then the name on the 
client certificate could be checked against login_trusted_networks in 
much the same way that web browsers work.


If you tell your web browser that you want to connect to 
www.example.com, the browser will check that the server's certificate 
matches "www.example.com".


In the present case, if you tell Dovecot (through the 
login_trusted_networks setting) to allow connections from 
"smtp.example.com", then Dovecot could check the name on the client's 
certificate matches "smtp.example.com".


More generally, example.com could issue client certificates with names 
matching "*.mua.example.com". Then you could tell Dovecot to allow 
connections from "*.mua.example.com" through the login_trusted_networks 
setting.


These usages could largely replace the IP host and CIDR subnet usages 
currently allowed in the login_trusted_networks setting but both could 
exist side by side.


Of course, more elaborate schemes could be devised involving database 
lookups, but the outlined proposal would be relatively easy to implement 
and cover a good majority of use cases.


The alternative is to force the use of application-specific certificate 
authorities, or just ignore it and hope that no one knows how to spoof 
network traffic.


  That's My two cents...

    Sean.


--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

feature request: add base64 variable modifier

[alex]

Hi,

It would be very convenient to have a base64 variable modifier. Main 
use-case is to base64-encode passwords when changing your hashing scheme.


With a base64 encoding modifier (e.g. %B) something like this would 
safely work:

userdb {
  driver = prefetch
  default_fields = plain_pass=%Bw
}
without things breaking when there are %-characters in the password, and 
without having to send the plaintext password to the database, as 
current solutions propose, which is never a good idea.


alternative solution:
adapt the generic hash-modifier to accept a none/plaintext 
hashing-scheme and use the base64 output functionality that is already 
available there.


Thanks!
Alex

Feature request: use`openid_configuration_url` to guess OIDC endpoints and keys

[Éloi Rivard]

Since version 2.3.16 dovecot has a openid_configuration_url [1] configuration
parameter. Here is the documentation about this parameter:

> Support for RFC 7628 OpenID Discovery (OIDC) can be achieved with 
> openid_configuration_url setting. Setting this causes Dovecot to report OIDC
> configuration URL as openid-configuration element in error JSON.

After reading the RFC I understand this brings some context to the error
messages, but at first glance I would have expected more from this parameter.

- Dovecot could read the userinfo_endpoint option [2] in the OIDC discovery
endpoint to guess the IDP userinfo endpoint [3], and make the dovecot
introspection_url parameter optional.

- Dovecot could read the introspection_endpoint option [4] in the OIDC discovery
endpoint to guess the IDP introspection endpoint [5], and make the dovecot
tokeninfo_url parameter optional. RFC8414 is still a draft though, but there
seems to be a convention about this parameter be called either
token_introspection_endpoint or introspection_endpoint. Maybe both could be
checked?

- Dovecot could read the jwks_uri [4] option in the OIDC discovery endpoint to
guess the IDP public keys, and make the local_validation_key_dict dovecot
parameter optional.

I would suggest to keep the values in introspection_url, tokeninfo_url and
local_validation_key_dict if defined, but use the values found in the OIDC
discovery endpoint by default.

I think this would really help using OAUTH with dovecot.
What do you think?

[1]
https://doc.dovecot.org/configuration_manual/authentication/oauth2/#openid-discovery
[2] https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata
[3] https://openid.net/specs/openid-connect-core-1_0.html#UserInfo
[4] https://datatracker.ietf.org/doc/html/rfc8414#section-2
[5] https://datatracker.ietf.org/doc/html/rfc7662

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.

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

[dc-ml]

hi.

we're just trying to re-structure a system and want to use dovcots
submission-ability.
because the github-repository have no entry for any issues at all, we're
sending this feature-fequest to this ML.

unfortunately there doesn't seem to be any option to drop the
received-header at all or at least hide the IP of the user.

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.

maybe this is possible to implement in near future?

thanks a lot.

best regards

d.

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.

feature request: doveadm purge taking guid argument

[Marc]

Hi Timo,

What about giving doveadm purge an argument to delete a specific message guid?

Is that a lot of work?

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.

feature request: prevent linking of email

[Marc]

What I have been doing wrong with testing expunged emails, is working with 
linked copies of emails. Although thunderbird copies the message, it looks like 
the message is NOT copied but linked.

If I drag 3 emails from my desktop to a folder INBOX/test4 and copy 1 message 
from INBOX to INBOX/test4. I have 4 messages in this folder. I now shift+del 
this folder. 

The expunged messages listing gives me the expected 3 messages 

doveadm -o 
mail_location=mdbox_deleted:/home/popusers/testtest/mdbox:INDEX=/home/popindex/testtest/index
 mailbox status -u testtest 'messages vsize' '*'
Sent messages=0 vsize=0
Drafts messages=0 vsize=0
INBOX/test2 messages=0 vsize=0
Junk messages=0 vsize=0
Trash messages=0 vsize=0
test3 messages=0 vsize=0
test1 messages=0 vsize=0
RESTORED messages=0 vsize=0
INBOX messages=3 vsize=18079344

Lets recover these:
doveadm -v import -u testtest 
'mdbox_deleted:/home/popusers/testtest/mdbox:INDEX=/home/popindex/testtest/index'
 RESTORED ALL

Now I have 3 messages back, as expected. 

From an end users perspective if you delete a folder with 4 emails, you want 
your restored backup to have 4 emails, not 3 because one is already somewhere 
else in your folder/mailbox structure. 

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.

feature request: maintain folder structure with expunged email

[Marc]

Currently when I am expunging messages, the expunged (to be purged messages) 
are counted / listed at INBOX.

Say for instance that a user would accidentally delete the mailbox 2014. The 
whole folder structure below it would be lost. If someone creates a folder 
structure, this folder structure has important added value.

I have my doubts on this design discarding of mailboxes like this. I think the 
use of mailboxes/folder structures is not valued enough. If you have a lot of 
email and put these emails in folders, the folder structure is part of the 
important information. Currently this 'important information' is lost with 
expunging. 

I can understand that it maybe quite an effort to implement preserving this 
information. But using the doveadm import to restore a lot of emails, is really 
not an option. 
I assume that also restoring email from a specific folder does not work. Say I 
delete foldera, folderb and folderc. How can I get back folderb.


[@]# mailbox-ls.sh testtest size
listing mailboxes of rittest:
Archive  msgs=0 vsize=0B
Archive/2011  msgs=0 vsize=0B
Archive/2012  msgs=0 vsize=0B
Archive/2013  msgs=8 vsize=7.4KiB
Archive/2014  msgs=0 vsize=0B
Archive/2015  msgs=0 vsize=0B
Archive/2016  msgs=0 vsize=0B
Archive/2017  msgs=1214 vsize=103MiB
Archive/2018  msgs=70 vsize=5.9MiB
Archive/2019  msgs=221 vsize=18MiB
Archive/Archive  msgs=1 vsize=2.4KiB
Archive/INBOX  msgs=0 vsize=0B
Drafts  msgs=9 vsize=16MiB  delmsgs=0 delvsize=0B
INBOX  msgs=51 vsize=107MiB  delmsgs=3 delvsize=18MiB
INBOX/test2  msgs=1 vsize=5.8MiB  delmsgs=0 delvsize=0B
Junk  msgs=2 vsize=2.0KiB  delmsgs=0 delvsize=0B
RESTORED  msgs=0 vsize=0B  delmsgs=0 delvsize=0B
RESTORED/INBOX  msgs=3 vsize=18MiB  delmsgs=0 delvsize=0B
Sent  msgs=17 vsize=7.3KiB  delmsgs=0 delvsize=0B
test1  msgs=3 vsize=12MiB  delmsgs=0 delvsize=0B
test3  msgs=0 vsize=0B  delmsgs=0 delvsize=0B
Trash  msgs=0 vsize=0B  delmsgs=0 delvsize=0B

Feature request: maintain folder/mailbox structure with expunging.

feature request: doveadm -Dv purge

[Marc]

Maybe list emails being purged

Feature Request: Redis support for username and TLS

[Mark Moseley]

I was wondering if there was any imminent support in 2.3.12+ for using a
username to log into Redis, as well as support for using TLS to connect to
Redis. And if not, I'd like to put in a feature request for those two
things (AUTH with username/password, and TLS connections to Redis).

Specifically, I was looking at using a username/password combo to log into
Redis for the quota_clone plugin. I found the 'password' param in the
source (not documented at https://wiki.dovecot.org/Dictionary). There's no
'username' param (the 'username' in the source seems to refer to the
mailbox, for the purpose of building the key name).

Redis 6 supports authenticating with a username and password, as well as
the ability to listen on a TLS-enabled port. Both of these significantly
improve security, combined with the new ACL system.

Obviously, these Redis 6 features are brand new, so I'd be shocked if they
were already supported. But it'd be awesome if those were added to Dovecot
:)

Currently, I've got a localhost Envoy proxy doing TCP proxying from
localhost+non-TLS to my Redis TLS port, which is a kludge at best. There's
a neat Envoy Redis proxy that *almost* does the trick but the Envoy Redis
proxy unfortunately doesn't support MULTI/EXEC, which Dovecot quota_clone
uses, or I'd be using that instead of a plain TCP proxy (since the Envoy
Redis proxy can use a username/password+tls to connect to the upstream
Redis).

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

Feature request.

[Rogier Wolff]

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

feature request for setting alternative pidfile

[Bjoern Jacke]

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

Feature request: ssl-cert config

[Marc Roos via dovecot]

I am not sure why this 

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

Feature request - blacklistd interaction

[Lefteris Tsintjelis via dovecot]

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

Feature request: additional commands for doveadm HTTP API

[Peter Kubica via dovecot]

Hi,

I hope this is correct way of making a feature request.

I like doveadm HTTP API very much and use it for Zabbix monitoring.
Would be possible to add "replicator status" and "auth test" doveadm 
commands to HTTP API?


Thanks.

Kind regards,
Peter

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

Feature request: exclude IP/network in allow_nets extra field

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

Feature request: client bind address for replication

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

John


--- dovecot-2.2.36/src/doveadm/doveadm-settings.c   2018-04-30 
15:52:05.0 +0200
+++ dovecot-2.2.36-new/src/doveadm/doveadm-settings.c   2019-01-04 
14:59:11.556270077 +0100
@@ -62,6 +62,7 @@
DEF(SET_UINT, doveadm_worker_count),
DEF(SET_IN_PORT, doveadm_port),
{ SET_ALIAS, "doveadm_proxy_port", 0, NULL },
+   DEF(SET_STR, doveadm_local_ip),
DEF(SET_STR, doveadm_username),
DEF(SET_STR, doveadm_password),
DEF(SET_STR, doveadm_allowed_commands),
@@ -91,6 +92,7 @@
.doveadm_socket_path = "doveadm-server",
.doveadm_worker_count = 0,
.doveadm_port = 0,
+   .doveadm_local_ip = "",
.doveadm_username = "doveadm",
.doveadm_password = "",
.doveadm_allowed_commands = "",
--- dovecot-2.2.36/src/doveadm/doveadm-settings.h   2017-10-05 
19:09:55.0 +0200
+++ dovecot-2.2.36-new/src/doveadm/doveadm-settings.h   2019-01-04 
14:57:32.906269791 +0100
@@ -19,6 +19,7 @@
const char *doveadm_socket_path;
unsigned int doveadm_worker_count;
in_port_t doveadm_port;
+   const char *doveadm_local_ip;
const char *doveadm_username;
const char *doveadm_password;
const char *doveadm_allowed_commands;
--- dovecot-2.2.36/src/doveadm/doveadm-util.c   2018-04-30 15:52:05.0 
+0200
+++ dovecot-2.2.36-new/src/doveadm/doveadm-util.c   2019-01-04 
15:26:09.326903786 +0100
@@ -100,19 +100,29 @@
 }
 
 static int
-doveadm_tcp_connect_port(const char *host, in_port_t port)
+doveadm_tcp_connect_port(const char *host, in_port_t port, char * my_ip)
 {
struct ip_addr *ips;
unsigned int ips_count;
int ret, fd;
-
+   struct ip_addr my_net_ip;
+   int use_my_ip = 0;
+if (strcmp(my_ip,"") == 0) {
+i_info("No doveadm_local_ip setting, local ip supplied by 
operating system");
+   }
+   if (net_addr2ip(my_ip, _net_ip)) {
+i_error("error using doveadm_local_ip setting %s",my_ip);
+   } else {
+i_info("Using doveadm_local_ip setting: %s",my_ip);
+   use_my_ip = 1;
+   }
alarm(DOVEADM_TCP_CONNECT_TIMEOUT_SECS);
ret = net_gethostbyname(host, , _count);
if (ret != 0) {
i_fatal("Lookup of host %s failed: %s",
host, net_gethosterror(ret));
}
-   fd = net_connect_ip_blocking([0], port, NULL);
+   fd = net_connect_ip_blocking([0], port, use_my_ip ? _net_ip : 
NULL);
if (fd == -1) {
i_fatal("connect(%s:%u) failed: %m",
net_ip2addr([0]), port);
@@ -121,7 +131,7 @@
return fd;
 }
 
-int doveadm_tcp_connect(const char *target, in_port_t default_port)
+int doveadm_tcp_connect(const char *target, in_port_t default_port, char * 
my_ip)
 {
const char *host;
in_port_t port;
@@ -130,18 +140,18 @@
i_fatal("Port not known for %s. Either set proxy_port "
"or use %s:port", target, target);
}
-   return doveadm_tcp_connect_port(host, port);
+   return doveadm_tcp_connect_port(host, port, my_ip);
 }
 
 int doveadm_connect_with_default_port(const char *path,
- in_port_t default_port)
+ in_port_t default_port, char * my_ip)
 {
int fd;
 
/* we'll assume UNIX sockets typically have an absolute path,
   or at the very least '/' somewhere. */
if (strchr(path, '/') == NULL)
-   fd = doveadm_tcp_connect(path, default_port);
+   fd = doveadm_tcp_connect(path, default_port, my_ip);
else {
fd = net_connect_unix(path);
if (fd == -1)
@@ -152,7 +162,7 @@
 
 int doveadm_connect(const char *path)
 {
-   return doveadm_connect_with_default_port(path, 0);
+   return doveadm_connect_with_default_port(path, 0, "");
 }
 
 int i_strccdascmp(const char *a, const char *b)
--- dovecot-2.2.36/src/doveadm/doveadm-util.h   2017-10-05 19:09:55.0 
+0200
+++ dovecot-2.2.36-new/src/doveadm/doveadm-util.h   2019-01-04 
14:55:52.263289702 +0100
@@ -13,9 +13,9 @@
 const char *unixdate2str(time_t timestamp);
 const char *doveadm_plugin_getenv(const char *name);
 int doveadm_connect(const char *path);
-int doveadm_tcp_connect(const char *target, in_port_t default_port);
+int doveadm_tcp_connect(const char *target, in_port_t default_port, char * 
my_ip);
 int doveadm_connect_with_default_port(const char *path,
-

SIS feature request

[Daniel Miller via dovecot]

I tried SIS a couple years ago - I was very excited with the resulting 
decrease in storage requirements but the undiagnosed intermittent issues 
became too significant to ignore so I switched away.  Recently I was 
thinking about it again.


The primary issue with SIS seemed to be links would be deleted even 
though the source attachment files and related mails still existed.  It 
was possible to either manually re-build the links or have a script scan 
the mail error log and perform such.


I haven't looked at the code - but a thought for a possible "temporary" fix:

    1.  Whatever function in dbox code that performs the deletion of 
links - prior to actually deleting call a new function that will verify 
if any mails exist that reference it.  A new function, without modifying 
existing code, may catch something the existing functions don't - and if 
it logs the fact that it was called and found something...perhaps we can 
find the flaw in the original algorithm.  Just a thought.


    2.  In the mail retrieval function, if the attachment link doesn't 
exist - perform the relevant scan through the attachment database and if 
found re-create the link automatically.  This should log an error but 
indicate the recovery.


--
Daniel

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

Feature request SCRAM-SHA-256

[Tributh via dovecot]

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

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.

Feature Request - Director Balance

[Webert de Souza Lima]

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.


Thank you for your time.

Webert Lima
MAV Tecnologia
Belo Horizonte, Brasil.

Re: doveadm feature request: move mailbox between users

[aki . tuomi]

> On July 17, 2016 at 2:20 PM Luigi Rosa <li...@luigirosa.com> wrote:
> 
> 
> aki.tu...@dovecot.fi wrote on 17/07/2016 12:37:
> 
> >> A feature request for doveadm: move (or copy) mailboxes between users
> >>
> >> Something like:
> >>
> >> doveadm movemailbox -s User1 -d User2  Old/Mail/Box Destin/Ation/Path
> 
> > You can do this with
> >   - mailbox create
> >   - move
> >   - delete
> 
> See thread "Moving Maildir folders"
> 
> The problem is to prune and graft some branches of the [Maildir] folder 
> structure between users.
> 
> For instance, when a user leaves an organization, some of their mailboxes 
> must 
> ne copied/moved to varius coleagues in order to ensure business continuity
> 
> 
> -- 
> 
> 
> Ciao,
> luigi
> 
> /
> +--[Luigi Rosa]--
> \
> 
> All great truths begin as 
blasphemies.
>  --George Bernard Shaw

We'll consider this. Thank you for the idea.

Aki

Re: doveadm feature request: move mailbox between users

[aki . tuomi]

> On July 17, 2016 at 1:29 PM Luigi Rosa <li...@luigirosa.com> wrote:
> 
> 
> A feature request for doveadm: move (or copy) mailboxes between users
> 
> Something like:
> 
> doveadm movemailbox -s User1 -d User2  Old/Mail/Box Destin/Ation/Path
> 
> (the same with copymailbox)
> 
> 
> Or something like that is already possible?
> 
> 
> 
> -- 
> 
> 
> Ciao,
> luigi
> 
> /
> +--[Luigi Rosa]--
> \
> 
> It's not enough that we do our best;
> sometimes we have to do what's required.
>  --Sir Winston Churchill

You can do this with 
 - mailbox create
 - move
 - delete

---
Aki Tuomi 
Dovecot oy

doveadm feature request: move mailbox between users

[Luigi Rosa]

A feature request for doveadm: move (or copy) mailboxes between users

Something like:

doveadm movemailbox -s User1 -d User2  Old/Mail/Box Destin/Ation/Path

(the same with copymailbox)


Or something like that is already possible?



--


Ciao,
luigi

/
+--[Luigi Rosa]--
\

It's not enough that we do our best;
sometimes we have to do what's required.
--Sir Winston Churchill

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

Feature Request

[Doug Hardie]

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.

— Doug

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

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

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

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

Re: [2.3 feature request]: multiple passwords for single user

[Arkadiusz Miśkiewicz]

On Monday 15 of December 2014, Rick Romero wrote:
   Quoting Arkadiusz Miśkiewicz ar...@maven.pl:
  Hi.
  
  I wonder if there any plans of finishing multiple passwords for single
  user
  feature?
  snip
  
  Untill that happens (not that great) workaround exists:
  http://wiki2.dovecot.org/Authentication/MultipleDatabases
  
   
 
 Whoops misfired
 
 Unless you want a single service to have multiple passwords,

I do want exactly that.

 which doesn't
 seem like a good idea to me, 

Good/bad depends on usage scenario and needs, so don't worry about this.

 use SQL if statements to separate by
 service/host.  
 
 http://www.dovecot.org/list/dovecot/2014-July/097140.html

That won't work in my scenario. I need two (or more) passwords for the same 
service.

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

[2.3 feature request]: multiple passwords for single user

[Arkadiusz Miśkiewicz]

Hi.

I wonder if there any plans of finishing multiple passwords for single user 
feature?

Few months old thread mentioned this:
http://www.dovecot.org/list/dovecot/2014-July/097217.html
and even a patch that unfortunately was never finished
http://dovecot.org/patches/2.0/auth-multi-password-2.0.diff

Multiple passwords for single user are great since allow easy password 
management for users. For example you could have one password on a laptop, one 
on a phone, one on a tablet. Revoking access to the device is as easy as 
dropping single password and it doesn't affect other devices. There are more 
use cases.

Untill that happens (not that great) workaround exists:
http://wiki2.dovecot.org/Authentication/MultipleDatabases

Thanks,
-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: [2.3 feature request]: multiple passwords for single user

[Rick Romero]

 Quoting Arkadiusz Miśkiewicz ar...@maven.pl:


Hi.

I wonder if there any plans of finishing multiple passwords for single
user
feature?
snip
Untill that happens (not that great) workaround exists:
http://wiki2.dovecot.org/Authentication/MultipleDatabases


No, just use multiple fields in SQL with IF statements.  Unless you want a
single login method to support multiple passwords - which doesn't seem like
a good idea to me.

Re: [2.3 feature request]: multiple passwords for single user

[Rick Romero]

 Quoting Arkadiusz Miśkiewicz ar...@maven.pl:


Hi.

I wonder if there any plans of finishing multiple passwords for single
user
feature?
snip

Untill that happens (not that great) workaround exists:
http://wiki2.dovecot.org/Authentication/MultipleDatabases

 


Whoops misfired

Unless you want a single service to have multiple passwords, which doesn't
seem like a good idea to me, use SQL if statements to separate by
service/host.  

http://www.dovecot.org/list/dovecot/2014-July/097140.html

Re: [Dovecot] Feature Request: handle mail connections of the same user from a same IP using just one mail process

[Alessio Cecchi]

Il 11/04/2014 17:49, morrison ha scritto:

Hi,

Dovecot Wiki states that mail process (IMAP/POP3) is able to handle multiple 
client connections as the same time to save CPU and memory resources (client_limit 
 1). Although this approach is not recommended due to latency and probably 
security issues, it does help increase the overall capacity of a mail server. Is 
it possible (or planned) to add a feature such that mail client connections of the 
same user from a same IP are directed to a same mail process? In most cases, such 
connections come from a same mail client (e.g. in Thunderbird, each mailbox is a 
connection). The end user (human being) can work on one mailbox at a time, the 
latency will be non-obvious. And since all data being processed belong to the same 
user, security is a non-issue.

Thanks,





Hi,

a features like this should be added:

https://fosdem.org/2014/interviews/2014-timo-sirainen/

=
The ability to save/restore IMAP connection state. This would allow 
getting rid of most of the long running memory-hungry idling IMAP 
processes by keeping the connections in a small number of IMAP-idle 
processes where they wait for something to happen. This also allows 
moving IMAP connections between servers. This could also improve 
performance of some webmail systems by having the webmail server 
remember the state as a string and then be able to quickly restore it 
with another IMAP command.

=

--
Alessio Cecchi is:
@ ILS - http://www.linux.it/~alessice/
on LinkedIn - http://www.linkedin.com/in/alessice
Assistenza Sistemi GNU/Linux - http://www.cecchi.biz
Cloud Email Hosting - http://www.qboxmail.com
@ PLUG - ex-Presidente, adesso senatore a vita, http://www.prato.linux.it

[Dovecot] Feature Request: handle mail connections of the same user from a same IP using just one mail process

[morrison]

Hi,

Dovecot Wiki states that mail process (IMAP/POP3) is able to handle multiple 
client connections as the same time to save CPU and memory resources 
(client_limit  1). Although this approach is not recommended due to latency 
and probably security issues, it does help increase the overall capacity of a 
mail server. Is it possible (or planned) to add a feature such that mail client 
connections of the same user from a same IP are directed to a same mail 
process? In most cases, such connections come from a same mail client (e.g. in 
Thunderbird, each mailbox is a connection). The end user (human being) can work 
on one mailbox at a time, the latency will be non-obvious. And since all data 
being processed belong to the same user, security is a non-issue.

Thanks,

 

Re: [Dovecot] Feature Request: handle mail connections of the same user from a same IP using just one mail process

[Reindl Harald]

Am 11.04.2014 17:49, schrieb morrison:
 Dovecot Wiki states that mail process (IMAP/POP3) is able to handle multiple 
 client connections as the same time to save CPU and memory resources 
 (client_limit  1). Although this approach is not recommended due to latency 
 and probably security issues, it does help increase the overall capacity of a 
 mail server. Is it possible (or planned) to add a feature such that mail 
 client connections of the same user from a same IP are directed to a same 
 mail process? In most cases, such connections come from a same mail client 
 (e.g. in Thunderbird, each mailbox is a connection). The end user (human 
 being) can work on one mailbox at a time, the latency will be non-obvious. 
 And since all data being processed belong to the same user, security is a 
 non-issue.

http://wiki2.dovecot.org/LoginProcess

High-performance mode is already there and no, forget
the broken idea but only the same user / ip because
you have no clue if it is a different user coming from
the same IP until the connection does auth

* if it does auth and it was not the same you are fucked
* you can't handle the connection to a different process
* even if you can - your login data are already sent

In most cases, such connections come from a same mail client
that made sense 10 or 15 years ago, these days *most cases*
are mobile clients coming through carrier-grade NAT, networks
behind a NAT or public access points shared by all sort of users

so no - you have only two choices

* performance
* security

any other conclusion base don a client IP is broken



signature.asc
Description: OpenPGP digital signature

[Dovecot] Patch feature request: hide passwords in doveconf -n by default

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

attached patch tries to hide any setting that ends in _password (singular) 
in the output of doveconf by default.


doveconf -n
- - passwords replaced by hidden
to prevent information leak when submitting bug reports

doveconf -n -P
- - passwords visible
when used by admins locally

doveconf -n -P -P
- - setting itself is not shown
to even hide that a password is set in the config

Warning: doveconf is used by internal programs as well, maybe they won't 
after the patch. Timo should check out the idea.
The passwords are left alone currently, if one queries one setting and if 
the values are saved to environment.


Kind regards,

- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBUyHQ0nD1/YhP6VMHAQIYkwf/aeiT4MMERJr1abZIHPv5zjvgHlyixwfM
huFD2CzbhWUoUlE4auAxUVDP+l/s7jlQzZ04y4vt2BdMauMUDSg8ZcFWxSkj+Veg
ZDjTVSP/v386ihH0TlGWXsVp1hCvzJUgylpQYbFwCJ3b58xs7p+8wb2l2Ngj/TTp
kmtl8mJ2Z5+MBJqz4IBxye7RXkTndHMC18EjVHxNkIIJ8kEUn7tbs0eljudZXSPD
q2gsG0PzvGTOUkuWWvWLVP4nTXBKMIffxX2SDNHmb1gHNV05zL8b5uth3PxUA7d6
NpXsnGHxCfOGf3FPbaTlGPfVpIX5IdTxZTRXHe++tDdlonZInM7V/g==
=73ZJ
-END PGP SIGNATURE-

dovecot_conf_hidepwd.diff.bz2
Description: Binary data

Re: [Dovecot] Feature Request doveadm who for all sockets or limits

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 12 Feb 2014, LuKreme wrote:


On 12 Feb 2014, at 09:12 , Steffen Kaiser skdove...@smail.inf.fh-brs.de wrote:

Some in-house program connected to auth-userdb, but did not closed the 
connection,


Is there a way to set a timeout on the open socket? Is it a socket?

Would lsof show the connections? (assuming your kernel is compatible with lsof, 
mine is not so I can't check).


I my case, it's an Unix socket: /var/run/dovecot/auth-userdb
lsof shows them as hex numbers - without end point. That way I found 
problematic program, because I had the chance to look, when the problem 
popped up.


- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBUv3Sl3D1/YhP6VMHAQK7TQf+Lx5iE9VEfqcQ5iqzKmp1ZP2nmbZURK26
559JIzmlWWiVXYcR4aCeCv2YXJLTaIyuTBmKjaPeOq8xnfmuoXnIb+t+5pkwScp1
jUaSkKD0fhTXxOCdwchbH9aDbTmcDsZi+ZHsaW367WgDD9ZRuRGlPQ6P4bZb6hv1
Z17wrIducYgHw+DCmpMGBDIWQg7EPaVE+RZWp8FatppeYSsaRtk2J+dJzgvQZ8AR
MpPUjiXgGgF4uLyHfwALNCN+12W9zez1koSf6LOuB+Sgkgil2ha1ScSWeFgCkyGt
btD08DO8dMK7COALVjhiPXDviPYhaJ57gP2GTAvGpVl0xgXHHi3Bjg==
=K2vC
-END PGP SIGNATURE-

[Dovecot] Feature Request doveadm who for all sockets or limits

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 10 Feb 2014, Steffen Kaiser wrote:


login success
imap: Error: Disconnected from auth server, aborting (client-pid=2296
client-id=17278)
imap-login: Info: Internal login failure (pid=2296 id=17278) (internal
failure, 1 successful auths)  .


for the archive:

I have found the client causing this error.
Some in-house program connected to auth-userdb, but did not closed the 
connection, rather it opened another connection to query the next user. 
Most of the time, the number of users was small, so nothing bad happened. 
But now and then up to 3000 users are to query. That broke the system.


However, my feature request remains:
Please add some way to query the current useage / fill of the limits. 
Maybe something like doveadm who for all sockets of Dovecot.


Kind regards,

- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBUvudhnD1/YhP6VMHAQID8gf/RP8Xmkd8SL22hUgTUojSEiyCyR29n/tt
0hjAEubtuMoTVPfGCz6hFyNOLqNowmJYiLsQarFyBX/peXm6yiGLMe4GJoa6N4Np
m0+bRUrBhh+IaQzw+PPfzVAeybQOFGtQ3xi/TXnM0qkoFrryZtLPaeqZeA0xMsDU
ObvINE2E+BHrTbBR/MCTuukpsmDSvORA7ixcIbXk//d5Q9+Mn/s7GIjQlHCAoC2U
2ER8H0Oe/VwDCBEUhJ0PFXMBSp2NEP9qU+R9hWtKG7uAfDCgN+rU+2Vlzi1ediWi
marcQJziO0MlOetrn+Vpqc7I4w0QNV1r9OImsvt6Ox/5d2iqVn8asA==
=ixQh
-END PGP SIGNATURE-

Re: [Dovecot] Feature Request doveadm who for all sockets or limits

[LuKreme]

On 12 Feb 2014, at 09:12 , Steffen Kaiser skdove...@smail.inf.fh-brs.de wrote:
 Some in-house program connected to auth-userdb, but did not closed the 
 connection, 

Is there a way to set a timeout on the open socket? Is it a socket?

Would lsof show the connections? (assuming your kernel is compatible with lsof, 
mine is not so I can't check).

 Please add some way to query the current useage / fill of the limits. Maybe 
 something like doveadm who for all sockets of Dovecot.

That does seem like a useful feature to have.

-- 
Part of the inhumanity of the computer is that, once it is competently
programmed and working smoothly, it is completely honest. - Isaac
Asimov

[Dovecot] Feature request about Info: Internal login failure (pid=2296 id=17278) (internal failure, 1 successful auths)

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

since some time I'm plagued by internal login failures. With v2.2.10 I got 
the some additional error, that I should raise the process_limit for the 
imap service, then I got the hint to raise vsz_limit for the lmtp and 
imap serverices. 
These hints are very helpful and are some sort of unique feature of 
Dovecot - descriptive error messages.


Now I have upgraded a Webfrontend behind imapproxy - Dovecot and get 
this during a phase in the day, several of messages go to large internal 
mailing lists and lots of users are connecting/disconnecting via IMAP, 
POP, Web:


login success
imap: Error: Disconnected from auth server, aborting (client-pid=2296 
client-id=17278)
imap-login: Info: Internal login failure (pid=2296 id=17278) (internal 
failure, 1 successful auths)  .


doveadm and to query the userdb [I have some processes that use Dovecot 
UserDB to query user data, which do not cache its information],  login 
into IMAP fail as well. Even connecting to the auth-userdb socket reveals 
no reaction - usually the VERSION prompts immediately. I now suppose that 
the deault auth_worker_max_count=30 is the culprit, because I query LDAP 
for passdb and userdb and client_count, but client_limit=0.


Would it be possible to add a warning to all limits that max out?
Or, if such generic error occurs, could Dovecot be enabled to dump a 
list of which limit is used up to which level? Or something like that.


Also, I'm surprised to find that the Internal login failure is at Info 
level only.


Also note: It is very possible that the problem is caused by a client that 
goes havoc.


==

Just to no trigger the post your config reply I give now and then 
myself:


# 2.2.10 (5432b55a2b87): /usr/local/dovecot-2.2.10/etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.8 
auth_cache_size = 10 M

auth_debug = yes
auth_mechanisms = plain login
auth_verbose = yes
base_dir = /var/run/dovecot2.2/
default_vsz_limit = 512 M
deliver_log_format = msgid=%m: %$ %p/%w %f %s
dict {
  acl = pgsql:/usr/local/dovecot-2.2.10/etc/dovecot/dovecot-dict-sql.conf.ext
  quota = pgsql:/usr/local/dovecot-2.2.10/etc/dovecot/dovecot-dict-sql.conf.ext
}
instance_name = dovecot2.2
lda_mailbox_autocreate = yes
lmtp_save_to_detail_mailbox = yes
log_path = /var/log/dovecot/dovecot2.2.log
log_timestamp = %F %H:%M:%S 
mail_debug = yes
mail_gid = vmail
mail_log_prefix = %Us(%u) [%p]: 
mail_max_userip_connections = 0
mail_plugins =  quota notify mail_log zlib acl
mail_shared_explicit_inbox = yes
mail_uid = vmail
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 ihave imapflags
namespace {
  list = children
  location = maildir:%%h/Maildir:INDEX=~/Maildir/shared/%%u
  prefix = users.%%u.
  separator = .
  type = shared
}
namespace inbox {
  inbox = yes
  location =
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox Sent Messages {
special_use = \Sent
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix = 
}

passdb {
  args = /usr/local/dovecot-2.2.10/etc/dovecot/dovecot-ldap.conf.ext
  driver = ldap
}
plugin {
  acl = vfile
  acl_shared_dict = proxy::acl
  antispam_allow_append_to_spam = yes
  antispam_backend = spool2dir
  antispam_spam = SPAM+ReportAsSPAM
  antispam_spool2dir_notspam = /tmp/spamspool/%%020lu-%%05lu-%u-H
  antispam_spool2dir_spam = /tmp/spamspool/%%020lu-%%05lu-%u-S
  antispam_trash = trash;TRASH;Trash;spam;SPAM;Spam;junk;JUNK;Junk;Deleted 
Items;Deleted Messages;GelAPY-schte Elemente;GelAPY-schte Objekte;Junk 
E-mail;Junk-E-Mail;INBOX.Trash;INBOX.TRASH;INBOX.trash
  mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename
  mail_log_fields = uid box msgid size vsize from subject
  quota = dict:User quota::proxy::quota
  quota_rule = *:storage=300MB
  quota_rule2 = Trash:storage=+30M
  recipient_delimiter = +
  sieve = ~/.dovecot.sieve
  sieve_dir = ~/sieve
  sieve_extensions = +imapflags
  sieve_max_actions = 0
  sieve_quota_max_storage = 3M
}
protocols = imap pop3 lmtp sieve
quota_full_tempfail = yes
service auth {
  unix_listener auth-client {
mode = 0766
  }
  unix_listener auth-userdb {
mode = 0766
user = vmail
  }
}
service dict {
  unix_listener dict {
group = vmail
mode = 0660
user = vmail
  }
}
service doveadm {
  unix_listener doveadm-server {
mode = 0666
  }
}
service imap-login {
  process_min_avail = 4
  service_count = 0
  vsz_limit = 768 M
}
service imap {
  process_limit = 1
  vsz_limit = 768 M
}
service lmtp {
  vsz_limit = 768 M
}
service managesieve-login {
  inet_listener sieve {
port = 4190
  }
  inet_listener sieve_deprecated {
port = 2000
  }
}
service pop3-login {
  

Re: [Dovecot] mail_log_events, but who exactly triggered events? [feature request]

[Arkadiusz Miśkiewicz]

On Thursday 30 of January 2014, Steffen Kaiser wrote:
 On Thu, 30 Jan 2014, Reindl Harald wrote:
  Am 30.01.2014 12:04, schrieb Arkadiusz Miśkiewicz:
  On Thursday 30 of January 2014, Reindl Harald wrote:
  Am 30.01.2014 10:50, schrieb Arkadiusz Miśkiewicz:
  mail_log_events is nice addition but how to log who exactly triggered
  particular event? For example 5 users from 5 IP addresses uses single
  imap user/mailbox.
  
  One of them deletes email and I'm logging delete related events. The
  only logged thing is:
  
  dovecot: imap(user): delete: box=INBOX, uid=673287,
  msgid=some@thing, size=1230

Here is a feature request:

Add optionally (or unconditionally) logging of session id in mail_log_events.

Timo, is this possible?

(the same session id that appears in login log entries: dovecot: imap-login: 
Login: user=someone2, method=PLAIN, rip=aaa, lip=yyy, 
mpid=11682, TLS, session=U1lD9y3xoQBPuvZx)

So for example this would get logged:
dovecot: imap(user): delete: box=INBOX, uid=673287, msgid=some@thing, 
size=1230, session=U1lD9y3xoQBPuvZx

 @Arkadiusz, please tell us, if 10 people use the same account name and
 password, how would you as a server behind the internet with a human
 brain differ those 10 individuals?
 
 The only idea I, personally, have is the IP address: Do they connect from
 different IP addresses _all_ the time? No NAT involved? Do you know who
 uses which IP address _all_ the time? If so, Dovecot logs the IP address
 during login and you can associate a PID with an IP address, IMHO you can
 add the remote IP address to the log string. Check out the variables page
 in the Wiki.
 
 But, frankly, _if_ you have someone, who is bad and deletes important
 mail, you should see sensible reason to disallow such work style.
 The next time you see yet another IP address and don't know the user
 again.

Ok, but why session id that's assigned at login cannot be logged in 
mail_log_events, too? Is there any technical problem with this approach?

It solves the problem (yes, assume different IP addresses; won't work 
obviously if the address is the same)

The discussion is now about changing the way service is used by people while 
I'm more interested in what dovecot can do or (enhancing) dovecot 
capabilities.

-- 
Arkadiusz Miśkiewicz, arekm / maven.pl

Re: [Dovecot] mail_log_events, but who exactly triggered events? [feature request]

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 4 Feb 2014, Arkadiusz Miśkiewicz wrote:


Date: Tue, 4 Feb 2014 13:09:15 +0100
From: Arkadiusz Miśkiewicz ar...@maven.pl
To: dovecot@dovecot.org
Subject: Re: [Dovecot] mail_log_events,
but who exactly triggered events? [feature request]

On Thursday 30 of January 2014, Steffen Kaiser wrote:

On Thu, 30 Jan 2014, Reindl Harald wrote:

Am 30.01.2014 12:04, schrieb Arkadiusz Miśkiewicz:

On Thursday 30 of January 2014, Reindl Harald wrote:

Am 30.01.2014 10:50, schrieb Arkadiusz Miśkiewicz:

mail_log_events is nice addition but how to log who exactly triggered
particular event? For example 5 users from 5 IP addresses uses single
imap user/mailbox.

One of them deletes email and I'm logging delete related events. The
only logged thing is:

dovecot: imap(user): delete: box=INBOX, uid=673287,
msgid=some@thing, size=1230


Here is a feature request:

Add optionally (or unconditionally) logging of session id in mail_log_events.

Timo, is this possible?

(the same session id that appears in login log entries: dovecot: imap-login:
Login: user=someone2, method=PLAIN, rip=aaa, lip=yyy,
mpid=11682, TLS, session=U1lD9y3xoQBPuvZx)

So for example this would get logged:
dovecot: imap(user): delete: box=INBOX, uid=673287, msgid=some@thing,
size=1230, session=U1lD9y3xoQBPuvZx


did you've tried this:
http://wiki2.dovecot.org/Variables
there is the session variable and the mail_log_prefix setting. Should 
work, IMHO.





@Arkadiusz, please tell us, if 10 people use the same account name and
password, how would you as a server behind the internet with a human
brain differ those 10 individuals?

The only idea I, personally, have is the IP address: Do they connect from
different IP addresses _all_ the time? No NAT involved? Do you know who
uses which IP address _all_ the time? If so, Dovecot logs the IP address
during login and you can associate a PID with an IP address, IMHO you can
add the remote IP address to the log string. Check out the variables page
in the Wiki.

But, frankly, _if_ you have someone, who is bad and deletes important
mail, you should see sensible reason to disallow such work style.
The next time you see yet another IP address and don't know the user
again.


Ok, but why session id that's assigned at login cannot be logged in
mail_log_events, too? Is there any technical problem with this approach?

It solves the problem (yes, assume different IP addresses; won't work
obviously if the address is the same)

The discussion is now about changing the way service is used by people while
I'm more interested in what dovecot can do or (enhancing) dovecot
capabilities.




- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBUvDil3D1/YhP6VMHAQKYPAf/Y19YFhmfNUcOa8AckcE5u1G9b36za9MH
HS2hcTjKI4k1iKHFhMS7cdKoeH0uHQaq0SWOhqH8jAssDh+YpnOTrmAdr2gJDHVi
rX9JSXoD/VgkQKptoc+EEgumEnHIrdu0GNjp5Jz2kKjM0prv+GscTJuoaSMhOjr2
xL/BxW3q85HsGmSQbxbHp5mcZiBZe0WFrz0U/vAfA0LO/mUBYfNmze+BXM867asc
aMEtMk9JahBUEPuNOzxqU9Qf70LlYkfV2Fw48+tpuGByG7yjkI5OXc8Flh47Z0jN
4OAHSPwVblh7LJuOM7DAlpPO8mbJOlVhMVxDisazxDwHO1oTq1rnPQ==
=oGnE
-END PGP SIGNATURE-

Re: [Dovecot] mail_log_events, but who exactly triggered events? [feature request]

[Arkadiusz Miśkiewicz]

On Tuesday 04 of February 2014, Steffen Kaiser wrote:
 On Tue, 4 Feb 2014, Arkadiusz Miśkiewicz wrote:
  Date: Tue, 4 Feb 2014 13:09:15 +0100
  From: Arkadiusz Miśkiewicz ar...@maven.pl
  To: dovecot@dovecot.org
  Subject: Re: [Dovecot] mail_log_events,
  
  but who exactly triggered events? [feature request]
  
  On Thursday 30 of January 2014, Steffen Kaiser wrote:
  On Thu, 30 Jan 2014, Reindl Harald wrote:
  Am 30.01.2014 12:04, schrieb Arkadiusz Miśkiewicz:
  On Thursday 30 of January 2014, Reindl Harald wrote:
  Am 30.01.2014 10:50, schrieb Arkadiusz Miśkiewicz:
  mail_log_events is nice addition but how to log who exactly
  triggered particular event? For example 5 users from 5 IP addresses
  uses single imap user/mailbox.
  
  One of them deletes email and I'm logging delete related events. The
  only logged thing is:
  
  dovecot: imap(user): delete: box=INBOX, uid=673287,
  msgid=some@thing, size=1230
  
  Here is a feature request:
  
  Add optionally (or unconditionally) logging of session id in
  mail_log_events.
  
  Timo, is this possible?
  
  (the same session id that appears in login log entries: dovecot:
  imap-login: Login: user=someone2, method=PLAIN, rip=aaa, lip=yyy,
  mpid=11682, TLS, session=U1lD9y3xoQBPuvZx)
  
  So for example this would get logged:
  dovecot: imap(user): delete: box=INBOX, uid=673287, msgid=some@thing,
  size=1230, session=U1lD9y3xoQBPuvZx
 
 did you've tried this:
 http://wiki2.dovecot.org/Variables
 there is the session variable and the mail_log_prefix setting. Should
 work, IMHO.

Wow, easy. Works nicely. Thanks!

-- 
Arkadiusz Miśkiewicz, arekm / maven.pl

[Dovecot] recipient_delimiter -- feature request

[Andrew Ray]

Hi,

It would be nice if the recipient_delimiter configuration option 
supported multiple recipient delimiters as Postfix now does.
e.g. now if I set: recipient_delimiter = +-  in Postfix, then 
test-extens...@sample.com and test+extens...@sample.com are both recognized.
But if I set: recipient_delimiter = +- in Dovecot, neither of the above 
are recognized and instead test+-extens...@sample.com is valid.


Well, presently this feature isn't that important to me, but I imagine 
it could be a source of confusion for people who are migrating from say 
qmail to postfix (as I am doing) and notice Postfix's cool ability to 
support both types of delimiters and assume Dovecot will as well (as I did).


Thanks,
Andrew Ray

--

Andrew Ray
+1 404-418-5443
+421 (0) 917 832 253
http://guns.freedomlives.net/

Re: [Dovecot] recipient_delimiter -- feature request

[Patrick Domack]

To make it work the current way, is simple.

--- a/src/lmtp/commands.c   2013-02-05 18:31:36.0 -0500
+++ b/src/lmtp/commands.c   2014-01-28 18:15:01.011677816 -0500
@@ -387,7 +387,7 @@
return;

domain = strchr(address, '@');
-   p = strstr(address, client-unexpanded_lda_set-recipient_delimiter);
+   p = strpbrk(address, client-unexpanded_lda_set-recipient_delimiter);
if (p != NULL  (domain == NULL || p  domain)) {
/* user+detail@domain */
*username_r = t_strdup_until(*username_r, p);


I would love for it though, to lookup and see if an mailbox exists  
with the delim first, then if it doesn't lookup just the username part.



Quoting Andrew Ray and...@freedomlives.net:


Hi,

It would be nice if the recipient_delimiter configuration option  
supported multiple recipient delimiters as Postfix now does.
e.g. now if I set: recipient_delimiter = +-  in Postfix, then  
test-extens...@sample.com and test+extens...@sample.com are both  
recognized.
But if I set: recipient_delimiter = +- in Dovecot, neither of the  
above are recognized and instead test+-extens...@sample.com is valid.


Well, presently this feature isn't that important to me, but I  
imagine it could be a source of confusion for people who are  
migrating from say qmail to postfix (as I am doing) and notice  
Postfix's cool ability to support both types of delimiters and  
assume Dovecot will as well (as I did).


Thanks,
Andrew Ray

--

Andrew Ray
+1 404-418-5443
+421 (0) 917 832 253
http://guns.freedomlives.net/

Re: [Dovecot] recipient_delimiter -- feature request

[Patrick Domack]

Quoting Patrick Domack patric...@patrickdk.com:


To make it work the current way, is simple.



I would love for it though, to lookup and see if an mailbox exists  
with the delim first, then if it doesn't lookup just the username  
part.



Quoting Andrew Ray and...@freedomlives.net:


Hi,

It would be nice if the recipient_delimiter configuration option  
supported multiple recipient delimiters as Postfix now does.
e.g. now if I set: recipient_delimiter = +-  in Postfix, then  
test-extens...@sample.com and test+extens...@sample.com are both  
recognized.
But if I set: recipient_delimiter = +- in Dovecot, neither of the  
above are recognized and instead test+-extens...@sample.com is valid.


Well, presently this feature isn't that important to me, but I  
imagine it could be a source of confusion for people who are  
migrating from say qmail to postfix (as I am doing) and notice  
Postfix's cool ability to support both types of delimiters and  
assume Dovecot will as well (as I did).


Thanks,
Andrew Ray

--

Andrew Ray
+1 404-418-5443
+421 (0) 917 832 253
http://guns.freedomlives.net/



Well, to answer my own wishlist, this isn't by no means complete, as I  
only use lmtp, so I didn't bother to patch lda, but logins already  
worked good the way it was, so just needed lmtp to match with delim  
first, then try again without it.


--- dovecot-2.2.10/src/lmtp/commands.c  2013-08-21 16:30:17.0 -0400
+++ dovecot-2.2.10/src/lmtp/commands.c  2014-01-28 20:18:12.303577376 -0500
@@ -387,7 +387,7 @@
return;

domain = strchr(address, '@');
-   p = strstr(address, client-unexpanded_lda_set-recipient_delimiter);
+   p = strpbrk(address, client-unexpanded_lda_set-recipient_delimiter);
if (p != NULL  (domain == NULL || p  domain)) {
/* user+detail@domain */
*username_r = t_strdup_until(*username_r, p);
@@ -536,7 +536,7 @@

memset(input, 0, sizeof(input));
input.module = input.service = lmtp;
-   input.username = username;
+   input.username = address;
input.local_ip = client-local_ip;
input.remote_ip = client-remote_ip;
input.local_port = client-local_port;
@@ -545,6 +545,16 @@
ret = mail_storage_service_lookup(storage_service, input,
  rcpt.service_user, error);

+if (ret=0  strlen(detail)0) {
+   input.username = username;
+   ret = mail_storage_service_lookup(storage_service, input,
+ rcpt.service_user, error);
+   } else if(ret0) {
+   username=t_strdup(address);
+   if(strlen(detail)0)
+   detail = ;
+   }
+
if (ret  0) {
prefix = t_strdup_printf(ERRSTR_TEMP_USERDB_FAIL_PREFIX,
 username);

Re: [Dovecot] Odd Feature Request - RBL blacklist lookup to prevent authentication

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 22 Oct 2013, Marc Perkel wrote:

I would like to have a list of IPs (hacker list) that I can do a lookup on so 
that if anyone tries to authenticate to dovecot they always fail if they are 
on my list.


I have the list - and the list is available as a DNS blacklist.

I'd like to have it work with both local IP lists or RBL lookup.

The idea is so hackers from known IP addresses never succeed.


Why would you let the auth happen at all? Is it some sort of tarpitting? 
Otherwise you could just block the IP with a firewall.


Maybe you can combine the deny AuthDatabase, as explained here:
http://wiki2.dovecot.org/Authentication/RestrictAccess?highlight=%28deny%29
with a socket auth demon:
http://wiki2.dovecot.org/AuthDatabase/Dict

So, you return success via the auth socket dict and use the remote IP as 
key, but success is turned into deny.


If Dovecot provides the feature I have about 1/2 million IP addresses of 
known current hackers to block.


Well, I do not like the notion one IP == one person, too many setups use 
NAT.


- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBUmd5xl3r2wJMiz2NAQLaVQf+KLz5cXy9u51KdVnoc2deJydbSuv0J8b1
IpQ2270EIKctTwtwABvYEEOM8o07S20kAL+vqBFBFgvS6pK/mgtm9fg/z1+GPgpu
S5ngfOuHw+NrmwSP/JSOGCezFXnccH2a7KVN47pgYVRKWEOMH+j0hbbrogfXcMRD
NMtI3GTDlPO0BVdXAavJxQylXbVYAZy5icrd/YkFyp6MkWCNOWkUYzOmr1/sAPZu
8t2t0SXXyfUc/gKHOdO8EGGbS2Bc2YRRO/M3iLScAiJWdo6uu4uCMOjPbZB+utqB
8Nicns0n9ZSCgIixYrjsfwE75nEjY8IwbSplL952sz4kHvG3+5MYrA==
=TH+V
-END PGP SIGNATURE-

[Dovecot] Odd Feature Request - RBL blacklist lookup to prevent authentication

[Marc Perkel]

I would like to have a list of IPs (hacker list) that I can do a lookup 
on so that if anyone tries to authenticate to dovecot they always fail 
if they are on my list.


I have the list - and the list is available as a DNS blacklist.

I'd like to have it work with both local IP lists or RBL lookup.

The idea is so hackers from known IP addresses never succeed.

If Dovecot provides the feature I have about 1/2 million IP addresses of 
known current hackers to block.


Anyone else interested in this?

Re: [Dovecot] Odd Feature Request - RBL blacklist lookup to prevent authentication

[Benny Pedersen]

Marc Perkel skrev den 2013-10-22 21:31:


Anyone else interested in this?


would you sell more ram later ?

basicly you like to have fail2ban to a central server logging via syslog 
?


if yes create more rules to fail2ban and show it on a wiki