Re: [SIEVE] pipe :copy to external program with arguments

[Reio Remma]

On 31.07.18 0:45, spamv...@googlemail.com wrote:

Hi all,

quick questions about sieve pipe:
I want to pipe spam messages to an external program with additional 
parameters


my spamlearn.sieve script:

require ["vnd.dovecot.pipe", "copy", "imapsieve"];
pipe :copy "mybin" ["-h 127.0.0.1:4 " , 
"markspam"];


I also tried:
pipe :copy "mybin" ["-h 127.0.0.1:4  
markspam"];
pipe :copy "mybin" ["-h 127.0.0.1:4 "] 
["markspam"];
pipe :copy :args ["-h 127.0.0.1:4  
markspam"] "mybin" ;


It never executes correct, it always ends with:
Error: sieve: Execution of script /my/path/to/spamlearn.sieve failed

So whats the correct syntax ?

What works is a single argument:
pipe :copy "myscript" ["markspam"];

Dovecot Version 2.3.2.1


My spam script is executed with:

pipe :copy "sa-learn-sieve.sh" ["spam", "${username}", "${message}"];

The latter two arguments are variables in the sieve script.

Good luck,
Reio

Re: dsync: expunge from pop3 does not replicate

[Jakub Lánský]

Hi Aki,

did you had any luck with reproducing this?

Thanks for answer
-- 
Jakub Lánský

IT administration/support technician
ja...@lansky.biz
GSM: +420776172737
Jabber/GTalk: le...@blesmrt.net

 Původní zpráva 
Od: Jakub Lánský 
Komu: Aki Tuomi , dovecot@dovecot.org
Předmět: Re: dsync: expunge from pop3 does not replicate
Datum: Thu, 26 Jul 2018 11:03:53 +0200

Yes, it should incoming mail to inbox, where replication was requested
(and mail was replicated succesfully, of course). After expunge via
POP3, replication was not called at all. (It doesn't happens on IMAP
connections, if I didn't mentioned in previous message)

Log:

Jul 26 10:54:11 mda11 dovecot:
lmtp(jakub@***)<339>: Debug: INBOX: Mailbox
opened because: lib-lda delivery
Jul 26 10:54:11 mda11 dovecot:
lmtp(jakub@***)<339>: Debug: Mailbox : Opened mail UID=1 because: copying
Jul 26 10:54:11 mda11 dovecot:
lmtp(jakub@***)<339>: Debug: replication:
Replication requested by 'mail_deliver_save', priority=2
Jul 26 10:54:11 mda11 dovecot:
lmtp(jakub@***)<339>: <
20180726105407.7b9cbf8d@muffycake> lenny@***/lenny@*** pop3 test mail
#2 -> lenny@*** 2651: saved mail to INBOX
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***)<2172><>: Debug: auth
USER input: jakub@*** uid=65534 quota_rule=*:bytes=3221225472
quota_rule2=*:messages=0
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***)<2172><>: Debug: Added
userdb setting: plugin/quota_rule=*:bytes=3221225472
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***)<2172><>: Debug: Added
userdb setting: plugin/quota_rule2=*:messages=0
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): auth USER input: jakub@*** uid=65534
quota_rule=*:bytes=3221225472 quota_rule2=*:messages=0
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): Added userdb setting:
plugin/quota_rule=*:bytes=3221225472
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): Added userdb setting:
plugin/quota_rule2=*:messages=0
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): Effective uid=65534, gid=65534,
home=/datastore/maildir/***/jakub
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): Quota root: name=User quota backend=dict
args=:proxy::sqlquota
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): Quota rule: root=User quota mailbox=*
bytes=3221225472 messages=0
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): Quota rule: root=User quota mailbox=*
bytes=3221225472 messages=0
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): Quota warning: bytes=3060164198 (95%)
messages=0 reverse=no command=quota-warning 95 jakub@*** *** size
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): Quota warning: bytes=0 messages=0 (95%)
reverse=no command=quota-warning 95 jakub@*** *** count
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): Quota grace: root=User quota bytes=1610612736
(50%)
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): dict quota: user=jakub@***,
uri=proxy::sqlquota, noenforcing=0
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): Namespace inbox: type=private, prefix=, sep=,
inbox=yes, hidden=no, list=yes, subscriptions=yes location=maildir:~/
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): maildir++: root=/datastore/maildir/***/jakub,
index=, indexpvt=, control=, inbox=/datastore/maildir/***/jakub, alt=
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug:
remote(10.3.13.52:54321): quota: quota_over_flag check:
quota_over_script unset - skipping
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug: Effective
uid=65534, gid=65534, home=/datastore/maildir/***/jakub
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug: Quota root:
name=User quota backend=dict args=:proxy::sqlquota
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug: Quota rule:
root=User quota mailbox=* bytes=3221225472 messages=0
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug: Quota rule:
root=User quota mailbox=* bytes=3221225472 messages=0
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug: Quota
warning: bytes=3060164198 (95%) messages=0 reverse=no command=quota-
warning 95 jakub@*** *** size
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug: Quota
warning: bytes=0 messages=0 (95%) reverse=no command=quota-warning 95
jakub@*** *** count
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug: Quota grace:
root=User quota bytes=1610612736 (50%)
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug: dict quota:
user=jakub@***, uri=proxy::sqlquota, noenforcing=0
Jul 26 10:54:11 mda11 dovecot: doveadm(jakub@***): Debug: Namespace
inbox: type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes,
su

Re: 2.3.2.1 - EC keys suppport?

[ѽ҉ᶬḳ℠]

>
>>> Perhaps for whose interested - IETF RFC 7027 specifies for TLS use:
>>>
>>> [ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ]
>>>
>>> And thus t1 would not work anyway. However, having tested r1 the result
>>> was just the same.
>>>
>>> A tcpdump during the openssl test [ s_server | s_client ] then revealed
>>> (TLSv1.2 Record Layer: Handshake Protocol: Client Hello) :
>>>
>>> Extension: supported_groups (len=10)
>>>     Type: supported_groups (10)
>>>     Length: 10
>>>     Supported Groups List Length: 8
>>>     Supported Groups (4 groups)
>>>     Supported Group: x25519 (0x001d)
>>>     Supported Group: secp256r1 (0x0017)
>>>     Supported Group: secp521r1 (0x0019)
>>>     Supported Group: secp384r1 (0x0018)
>>>
>>> Apparently [ brainpool ] would apparently not fit into any of those
>>> groups. Perhaps a bug in OpenSSL 1.1.0h thus.
>>>
>>>
>> Turned out not being a bug in OpenSSL after all. From the cli it works
>> with no issues this way:
>>
>> [ openssl s_server -cert ec.cert.pem -key ec.key.pem -port  -curves
>> brainpoolP512r1 ]
>> [ openssl s_client -connect localhost: -curves brainpoolP512r1 ]
>>
>> I am not familiar really with the OpenSSL API and only roughly gather
>> that the app (dovecot) would have to make the API call [
>> SSL_CTX_set1_groups_list ]
>> (https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_groups.html)
>> in order to support those curves.
>>
>>
> Whoops.
>
> We have a setting called `ssl_curve_list` in dovecot, and I tried using
> that when I was testing. Turns out that there is a bug preventing that
> setting from being used. If you are compiling yourself, you can use the
> attached patch to fix this.
>
> After applying, you can set
>
> ssl_curve_list = brainpoolP512r1
>
> And then you can connect again.
>
> Aki

Meantime I stumbled over that setting and was like 'yeah - what are you
blubbering about when dovecot caters for it already'. That stopped when
testing the setting ... like you said it is a bug apparently.

Now about compiling... that is not really my turf unless it is
absolutely necessary. Time being I will (have to) work around with [ 
ssl_alt_key/cert ] and will notify the downstream repo maintainer about
the patch, assuming that needs all that compiling I cannot just modify
some file manually.

Re: Welcome plugin - user and domain vars?

[Aki Tuomi]

On 31.07.2018 06:07, Tony wrote:
> Hi List,
>
> I have multiple mail domains and depending on the domain name was
> looking for a way to pass the user and domain into a welcome.sh
> script. I looked at the quota script and saw of the 3 vars one of them
> is for the user.
>
> BOUNDARY="$1"
> USER="$2"
> MSG=""
>
> For the username - could we still reference USER="$2" in order to pass
> the username in the welcome email or is this only supported with the
> quota plugin?
>
> For the domain - how could one pass the 1st time login user's mail
> domain to the script? I looked at the welcome-plugin.c source, but
> didn't find anything that might reference a domain. Ideally I was
> hoping maybe something similar to the quota script could work..
>
>  MSG=""
>  if [[ "$DOMAIN" = "domain.net" ]]; then
>     MSG="..."
>  elif [[ "$DOMAIN" = "domain.com" ]]; then
>     MSG="..."
>  elif [[ "$DOMAIN" = "domain.me" ]]; then
>     MSG="..."
>  elif [[ "$DOMAIN" = "domain.email" ]]; then
>     MSG="..."
>  fi
>
> Thanks for any suggestions.
>
> Cheers,
> Tony

https://wiki.dovecot.org/Plugins/Welcome

You can use the 'welcome_script = welcome %u' to do this, by changing it
to 'welcome_script = welcome %u %Ld' or maybe 'welcome_script = %Ln %Ln'?

Re: 2.3.2.1 - EC keys suppport?

[Aki Tuomi]

On 31.07.2018 03:32, ѽ҉ᶬḳ℠ wrote:
>> Perhaps for whose interested - IETF RFC 7027 specifies for TLS use:
>>
>> [ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ]
>>
>> And thus t1 would not work anyway. However, having tested r1 the result
>> was just the same.
>>
>> A tcpdump during the openssl test [ s_server | s_client ] then revealed
>> (TLSv1.2 Record Layer: Handshake Protocol: Client Hello) :
>>
>> Extension: supported_groups (len=10)
>>     Type: supported_groups (10)
>>     Length: 10
>>     Supported Groups List Length: 8
>>     Supported Groups (4 groups)
>>     Supported Group: x25519 (0x001d)
>>     Supported Group: secp256r1 (0x0017)
>>     Supported Group: secp521r1 (0x0019)
>>     Supported Group: secp384r1 (0x0018)
>>
>> Apparently [ brainpool ] would apparently not fit into any of those
>> groups. Perhaps a bug in OpenSSL 1.1.0h thus.
>>
>>
> Turned out not being a bug in OpenSSL after all. From the cli it works
> with no issues this way:
>
> [ openssl s_server -cert ec.cert.pem -key ec.key.pem -port  -curves
> brainpoolP512r1 ]
> [ openssl s_client -connect localhost: -curves brainpoolP512r1 ]
>
> I am not familiar really with the OpenSSL API and only roughly gather
> that the app (dovecot) would have to make the API call [
> SSL_CTX_set1_groups_list ]
> (https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_groups.html)
> in order to support those curves.
>
>
Whoops.

We have a setting called `ssl_curve_list` in dovecot, and I tried using
that when I was testing. Turns out that there is a bug preventing that
setting from being used. If you are compiling yourself, you can use the
attached patch to fix this.

After applying, you can set

ssl_curve_list = brainpoolP512r1

And then you can connect again.

Aki
>From 71ceeaaed73af48eb2cdfd2e1d953ee645c2e9b2 Mon Sep 17 00:00:00 2001
From: Aki Tuomi 
Date: Tue, 31 Jul 2018 08:45:29 +0300
Subject: [PATCH] lib-master: Copy ssl_curve_list setting

Otherwise it won't get used.

Broken in 30dca95419
---
 src/lib-master/master-service-ssl-settings.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/lib-master/master-service-ssl-settings.c b/src/lib-master/master-service-ssl-settings.c
index 2434e3632c..2bc59b0f4d 100644
--- a/src/lib-master/master-service-ssl-settings.c
+++ b/src/lib-master/master-service-ssl-settings.c
@@ -213,4 +213,5 @@ void master_service_ssl_settings_to_iostream_set(
 	set_r->prefer_server_ciphers = ssl_set->ssl_prefer_server_ciphers;
 	set_r->compression = ssl_set->parsed_opts.compression;
 	set_r->tickets = ssl_set->parsed_opts.tickets;
+	set_r->curve_list = p_strdup(pool, ssl_set->ssl_curve_list);
 }
-- 
2.14.3

Re: uid problem

[Aki Tuomi]

You could run dovecot-lda as root. It will setuid to correct account.


---Aki TuomiDovecot oy
 Original message From: Andras Kemeny  Date: 
31/07/2018  04:46  (GMT+02:00) To: dovecot@dovecot.org Subject: uid problem 
hi,

contacting this mailing list is my last-ditch effort to somehow come to 
a working configuration where postfix "ends in" dovecot, IE for special 
LDAP-based users, featured in the virtual mailbox delivery, dovecot 
would act as LDA.

here's the deal.

i've set up dovecot's access to the LDAP server, and for the purposes of 
being an IMAP server and a SASL auth backend, dovecot works brilliantly 
and without a glitch. i can access my test mailbox (in maildir format), 
i can use the LDA as root and it delivers the message correctly (after a 
switch to the target user's UID), and even postfix's submission works 
with dovecot as its SASL backend.

what does not work is dovecot as LDA from postfix.

i'm getting these errors in the log:

Jul 31 03:40:40 rhyno dovecot: lda(aik): Error: user aik: Auth USER 
lookup failed
Jul 31 03:40:40 rhyno dovecot: auth: Error: userdb(aik): client doesn't 
have lookup permissions for this user: userdb uid (10001) doesn't match 
peer uid (5000) (to bypass this check, set: service auth { unix_listener 
/var/run/dovecot/auth-userdb { mode=0777 } })
Jul 31 03:40:40 rhyno dovecot: lda: Fatal: Internal error occurred. 
Refer to server log for more information.

for the sake of clarity, i've tried the "to bypass this check" 
instructions, didn't help.

also, for the sake of operational clarity, "aik" is the LDAP account 
with the following parameters:

dn: uid=aik,ou=People,dc=rhyno,dc=tech
objectClass: account
objectClass: posixAccount
objectClass: postfixUser
cn: aik
uid: aik
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/aik
loginShell: /bin/sh
gecos: aik
description: User account
structuralObjectClass: account
entryUUID: db947584-0369-1038-98b3-675e2f0cea17
creatorsName: cn=admin,dc=rhyno,dc=tech
createTimestamp: 20180613152616Z
email: ***
userPassword:: *
mailacceptinggeneralid: andras.kemeny
mailacceptinggeneralid: kemeny.andras
mailacceptinggeneralid: aik
mailacceptinggeneralid: pdx
mailacceptinggeneralid: @rhyno.tech
mailacceptinggeneralid: @rhynotechnologies.com
maildrop: aik

and postfix's master.cf says:

dovecot   unix  -   n   n   -   -   pipe
   flags=ODRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -e -f 
${sender} -d ${user}

so i'm stuck at this point. obviously, if the LDA is spawned with 
vmail:vmail perms, it cannot become uid 10001 (btw, the LDAP and passwd 
accounts were once connected, but for security reasons, the connection 
has been severed -- still the /home/aik/mail dir is owned by uid 10001 etc).

what am i doint wrong?

thanks,
a

Welcome plugin - user and domain vars?

[Tony]

Hi List,

I have multiple mail domains and depending on the domain name was 
looking for a way to pass the user and domain into a welcome.sh script. 
I looked at the quota script and saw of the 3 vars one of them is for 
the user.


BOUNDARY="$1"
USER="$2"
MSG=""

For the username - could we still reference USER="$2" in order to pass 
the username in the welcome email or is this only supported with the 
quota plugin?


For the domain - how could one pass the 1st time login user's mail 
domain to the script? I looked at the welcome-plugin.c source, but 
didn't find anything that might reference a domain. Ideally I was hoping 
maybe something similar to the quota script could work..


 MSG=""
 if [[ "$DOMAIN" = "domain.net" ]]; then
MSG="..."
 elif [[ "$DOMAIN" = "domain.com" ]]; then
MSG="..."
 elif [[ "$DOMAIN" = "domain.me" ]]; then
MSG="..."
 elif [[ "$DOMAIN" = "domain.email" ]]; then
MSG="..."
 fi

Thanks for any suggestions.

Cheers,
Tony

Re: dovecot 2.3.x, ECC and wildcard certificates, any issues

[ѽ҉ᶬḳ℠]

>> That is one of the reasons I do not bother since long with public CAs
>> but rather deploy my own, including own OSCP responder.
> May I ask, how you create a CA which is valid for clients without them
> having to install your root cert?
>

> and CA trust in clients. Latter though could be easily overcome if
browser and email clients were to support DNSSEC/DANE validation.

That is where DANE/TLSA comes in but it requires DNSSEC/DANE validation
in the client and of course DNSSEC and TLSA records in the domain's DNS.
Notwithstanding that the upstream DNS resolvers utilized by clients need
to support DNSSEC queries/answers as well.

Whatever the reasons for lacking such validation support in most of the
clients (incl. web browsers) one speculative is that it would kill
commercial CAs (as such Let's Encrypt is one too through their
sponsors), or at least has the potential to diminish their business (model).

Suppose we are not hijacking this thread furthermore and avoid earning a
discontent eventually ... ;)

Re: dovecot 2.3.x, ECC and wildcard certificates, any issues

[Helmut K. C. Tessarek]

On 2018-07-30 19:45, ѽ҉ᶬḳ℠ wrote:
> That is one of the reasons I do not bother since long with public CAs
> but rather deploy my own, including own OSCP responder.

May I ask, how you create a CA which is valid for clients without them
having to install your root cert?

Cheers,
 K. C.

-- 
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/



signature.asc
Description: OpenPGP digital signature

uid problem

[Andras Kemeny]

hi,

contacting this mailing list is my last-ditch effort to somehow come to 
a working configuration where postfix "ends in" dovecot, IE for special 
LDAP-based users, featured in the virtual mailbox delivery, dovecot 
would act as LDA.


here's the deal.

i've set up dovecot's access to the LDAP server, and for the purposes of 
being an IMAP server and a SASL auth backend, dovecot works brilliantly 
and without a glitch. i can access my test mailbox (in maildir format), 
i can use the LDA as root and it delivers the message correctly (after a 
switch to the target user's UID), and even postfix's submission works 
with dovecot as its SASL backend.


what does not work is dovecot as LDA from postfix.

i'm getting these errors in the log:

Jul 31 03:40:40 rhyno dovecot: lda(aik): Error: user aik: Auth USER 
lookup failed
Jul 31 03:40:40 rhyno dovecot: auth: Error: userdb(aik): client doesn't 
have lookup permissions for this user: userdb uid (10001) doesn't match 
peer uid (5000) (to bypass this check, set: service auth { unix_listener 
/var/run/dovecot/auth-userdb { mode=0777 } })
Jul 31 03:40:40 rhyno dovecot: lda: Fatal: Internal error occurred. 
Refer to server log for more information.


for the sake of clarity, i've tried the "to bypass this check" 
instructions, didn't help.


also, for the sake of operational clarity, "aik" is the LDAP account 
with the following parameters:


dn: uid=aik,ou=People,dc=rhyno,dc=tech
objectClass: account
objectClass: posixAccount
objectClass: postfixUser
cn: aik
uid: aik
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/aik
loginShell: /bin/sh
gecos: aik
description: User account
structuralObjectClass: account
entryUUID: db947584-0369-1038-98b3-675e2f0cea17
creatorsName: cn=admin,dc=rhyno,dc=tech
createTimestamp: 20180613152616Z
email: ***
userPassword:: *
mailacceptinggeneralid: andras.kemeny
mailacceptinggeneralid: kemeny.andras
mailacceptinggeneralid: aik
mailacceptinggeneralid: pdx
mailacceptinggeneralid: @rhyno.tech
mailacceptinggeneralid: @rhynotechnologies.com
maildrop: aik

and postfix's master.cf says:

dovecot   unix  -   n   n   -   -   pipe
  flags=ODRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -e -f 
${sender} -d ${user}


so i'm stuck at this point. obviously, if the LDA is spawned with 
vmail:vmail perms, it cannot become uid 10001 (btw, the LDAP and passwd 
accounts were once connected, but for security reasons, the connection 
has been severed -- still the /home/aik/mail dir is owned by uid 10001 etc).


what am i doint wrong?

thanks,
a

Re: 2.3.2.1 - EC keys suppport?

[ѽ҉ᶬḳ℠]

> Perhaps for whose interested - IETF RFC 7027 specifies for TLS use:
>
> [ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ]
>
> And thus t1 would not work anyway. However, having tested r1 the result
> was just the same.
>
> A tcpdump during the openssl test [ s_server | s_client ] then revealed
> (TLSv1.2 Record Layer: Handshake Protocol: Client Hello) :
>
> Extension: supported_groups (len=10)
>     Type: supported_groups (10)
>     Length: 10
>     Supported Groups List Length: 8
>     Supported Groups (4 groups)
>     Supported Group: x25519 (0x001d)
>     Supported Group: secp256r1 (0x0017)
>     Supported Group: secp521r1 (0x0019)
>     Supported Group: secp384r1 (0x0018)
>
> Apparently [ brainpool ] would apparently not fit into any of those
> groups. Perhaps a bug in OpenSSL 1.1.0h thus.
>
>

Turned out not being a bug in OpenSSL after all. From the cli it works
with no issues this way:

[ openssl s_server -cert ec.cert.pem -key ec.key.pem -port  -curves
brainpoolP512r1 ]
[ openssl s_client -connect localhost: -curves brainpoolP512r1 ]

I am not familiar really with the OpenSSL API and only roughly gather
that the app (dovecot) would have to make the API call [
SSL_CTX_set1_groups_list ]
(https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_groups.html)
in order to support those curves.

Re: dovecot 2.3.x, ECC and wildcard certificates, any issues

[ѽ҉ᶬḳ℠]

That is one of the reasons I do not bother since long with public CAs
but rather deploy my own, including own OSCP responder.

Which has of course has some drawbacks like redundancy, resilience,
bandwidth provision, geographical spread, implementing CA security
standards and CA trust in clients. Latter though could be easily
overcome if browser and email clients were to support DNSSEC/DANE
validation.

It may not help you in the short term now but perhaps something to
consider long term for the benefit of controlling the certificate
handling/signing, depending on the CA scale.

> Hello,
>
> I have discovered what I believe is the issue after hearing back from
> Aquamail. And that is that android 7 which I'm running 7.0 that is,
> only supports up to the p256 ecc curve. This brings up a question to
> users of letsencrypt, when you revoke a certificate does it take it
> out on the usage as well? I've got one domain that says i've issued to
> many certificates for it and no more can be issued, thought I was
> using the staging server. I'd like to get those certs off the
> letsencrypt servers so I can make a new one using the p256 curve. Does
> anyone know if this is doable? Using acme.sh I tried --revoke which
> revoked one cert but letsencrypt still would not let me issue another.
>
> Thanks.
> Dave.
>
>
> On 7/30/18, Aki Tuomi  wrote:
>> I don't know how to get both RSA and ECC cert from letsencrypt.
>>
>> Aki
>>
>>> On 30 July 2018 at 20:43 David Mehler  wrote:
>>>
>>>
>>> Hello,
>>>
>>> What acme implementation do you use for your letsencrypt certificates?
>>> If it's acme.sh how do you get both rsa and ecc certificates? What
>>> configuration options are you using in your configuration of services
>>> to allow access to both rsa and ecc?
>>>
>>> Thanks.
>>> Dave.
>>>
>>>
>>> On 7/30/18, David Mehler  wrote:
 Hello,

 The client in question is the latest version of AquaMail running on
 android.

 Thanks.
 Dave.


 On 7/30/18, Aki Tuomi  wrote:
> You should, in practice, enable both. This gives best client
> compability.
> It
> is possible you have clients that cannot understand ECC certificates?
> You
> can use ssl_alt_cert to provide RSA cert too.
>
> Aki
>
>> On 30 July 2018 at 20:05 David Mehler  wrote:
>>
>>
>> Hi,
>>
>> Thanks, good news is that worked. Bad news is it all looks good which
>> means I do not know hwhy my remote clients can't get their email,
>> looked like from the logs it was that.
>>
>> Would 143 be better or 993 for the external clients?
>>
>> Thanks.
>> Dave.
>>
>>
>> On 7/30/18, Aki Tuomi  wrote:
 On 30 July 2018 at 19:16 David Mehler 
 wrote:


 Hello,

 Does dovecot 2.3.x have any issues recognizing or using
 certificates
 that are ECC and wildcard? I'm trying to switch my letsencrypt
 implementation from acme-client which does not support either of
 those
 capabilities to acme.sh which does. Since then external clients
 checking their email has not worked. A manual telnet to
 mail.example.com 993 gives a connected message but then nothing no
 greeting or capabilities.

 The certificate is for example.com with an alt name of
 *.example.com
 if that's not right let me know, i'm not sure about that one,
 connecting to the web sites of these pages seems noticeably
 slower,
 I'm wondering if both of these issues aren't key related?

 Thanks.
 Dave.
>>> These both should be fine.
>>>
>>> Port 993 is TLS encrypted, you should use openssl s_client -connect
>>> server:993
>>>
>>> Aki
>>>

Re: mdbox_deleted proper syntax

[Johan Huldtgren]

I do not know, the data shown below was me trying to understand the
command and how it works, once I knew how the command worked I could
then look at the user in question's mailbox and see how it looked.

my question really boiled down to how do I use the mdbox_deleted
storage in the correct way? This led me down the rabbit hole of
fetch vs import. could you provide a correct example of using
mdbox_deleted with doveadm fetch?

thanks,

.jh

On 2018/07/29 23:48, Aki Tuomi wrote:
> Are you sure you have deleted mails and not just Trashed mails?
> 
> Aki
> 
> 
> On 26.07.2018 19:23, Johan Huldtgren wrote:
>> hello,
>>
>> on the wiki, https://wiki2.dovecot.org/MailboxFormat/dbox, it says that one 
>> can
>> use either doveadm fetch or doveadm import, however I can find no correct 
>> syntax
>> with fetch that'll actually work. Is the idea to simply override the
>> mail_location with -o ? That seems to work for doveadm mailbox but not for
>> doveadm fetch or search
>>
>> # doveadm -f table mailbox status -u johan all dovecot
>> mailbox messages recent uidnext uidvalidity unseen highestmodseq vsize 
>> guid firstsaved
>> dovecot 00  1   1362145026  0  1 164208086 
>> 64bd9f0003af30519004b9256959 1471825482
>>
>> # doveadm -f table -o "mail_location=mdbox_deleted:~/mdbox" mailbox status 
>> -u johan all dovecot
>> mailbox messages recent uidnext uidvalidity unseen highestmodseq vsize guid  
>>firstsaved
>> dovecot 00  1   0   0  1 0 
>> ddb9421479f0595bf21b0100b9256959 18446744073709551615
>>
>>
>> # doveadm -f flow fetch -u johan size.virtual mailbox dovecot
>> size.virtual=2869
>> size.virtual=2960
>> size.virtual=8023
>> size.virtual=6683
>> ...
>> #
>>
>> # doveadm -f flow -o "mail_location=mdbox_deleted:~/mdbox" fetch -u johan 
>> size.virtual mailbox dovecot
>> #
>>
>> # doveadm search -u johan mailbox dovecot subject "LMTP Log"
>> 64bd9f0003af30519004b9256959 8642
>> 64bd9f0003af30519004b9256959 21302
>> 64bd9f0003af30519004b9256959 21373
>> 64bd9f0003af30519004b9256959 21420
>> 64bd9f0003af30519004b9256959 21434
>> 64bd9f0003af30519004b9256959 21435
>> 64bd9f0003af30519004b9256959 21460
>> 64bd9f0003af30519004b9256959 21461
>> 64bd9f0003af30519004b9256959 21463
>> 64bd9f0003af30519004b9256959 23684
>>
>> # doveadm -o "mail_location=mdbox_deleted:~/mdbox" search -u johan mailbox 
>> dovecot subject "LMTP Log"
>> #
>>
>>
>> What I'm really trying to accomplish is see if a mail which a user deleted 
>> still exists in mdbox_deleted, so I
>> wanted to do a fetch / search to see and then try to copy / import that 
>> message back.
>>
>> This is on OpenBSD 6.3-current with dovecot 2.2.36, doveconf -n below.
>>
>> thanks,
>>
>> .jh
>>
>> ---
>>
>> # 2.2.36 (1f10bfa63): /etc/dovecot/dovecot.conf
>> # Pigeonhole version 0.4.24 (124e06aa)
>> # OS: OpenBSD 6.3 amd64
>> # Hostname: www.example.com
>> auth_mechanisms = plain login
>> first_valid_gid = 0
>> first_valid_uid = 507
>> imap_client_workarounds = delay-newmail tb-extra-mailbox-sep tb-lsub-flags
>> imap_id_log = *
>> last_valid_uid = 1059
>> listen = 127.0.0.1
>> mail_home = /home/vmail/%d/%n
>> mail_location = mdbox:~/mdbox
>> mail_plugins = stats fts fts_solr
>> mail_privileged_group = _dovecot
>> mailbox_list_index = yes
>> managesieve_notify_capability = mailto
>> managesieve_sieve_capability = fileinto reject envelope encoded-character 
>> vacation subaddress comparator-i;ascii-numeric relational regex imap4flags 
>> copy include variables body enotify environment mailbox date index ihave 
>> duplicate mime foreverypart extracttext spamtest spamtestplus virustest
>> mbox_write_locks = fcntl
>> mmap_disable = yes
>> namespace {
>>   inbox = yes
>>   location =
>>   mailbox spam {
>> auto = subscribe
>> special_use = \Junk
>>   }
>>   mailbox drafts {
>> auto = subscribe
>> special_use = \Drafts
>>   }
>>   mailbox sent-mail {
>> auto = subscribe
>> special_use = \Sent
>>   }
>>   mailbox trash {
>> auto = subscribe
>> autoexpunge = 30 days
>> special_use = \Trash
>>   }
>>   prefix =
>>   separator = /
>>   subscriptions = yes
>>   type = private
>> }
>> passdb {
>>   args = /etc/dovecot/dovecot-pgsql.conf
>>   driver = sql
>> }
>> passdb {
>>   args = /etc/dovecot/dovecot-pgsql2.conf
>>   driver = sql
>> }
>> passdb {
>>   args = cache_key=%u%r%l *
>>   driver = bsdauth
>> }
>> plugin {
>>   antispam_backend = mailtrain
>>   antispam_mail_notspam = learn_ham
>>   antispam_mail_sendmail = /usr/local/bin/rspamc
>>   antispam_mail_sendmail_args = -h;127.0.0.1:11334;-P;q1
>>   antispam_mail_spam = learn_spam
>>   antispam_spam = caughtspam
>>   antispam_trash = trash
>>   fts = solr
>>   fts_autoindex = yes
>>   fts_solr = url=http://127.0.0.1:8983/solr/dovecot/
>>   recipient_delimiter = +
>>   sieve = file:~/sieve;active=~/.dovecot.sieve
>>   s

Re: Doveadm protocol; dovecot v2.2.10

[Michael Slusarz]

> On July 30, 2018 at 2:07 PM David White  wrote:
>
> I’m currently on v2.2.10 and it appears the doveadm protocol command set is 
> limited to just the “mailbox” commands and the http protocol hasn’t been 
> implemented.
> 
> Is the doveadm http protocol still experimental in v2.3.2?

No.

michael

Re: dovecot 2.3.x, ECC and wildcard certificates, any issues

[Felipe Gasper]

Revocation doesn’t remove the certificates; it just marks them as invalid when 
a TLS client bothers to check.

-FG

> On Jul 30, 2018, at 6:45 PM, David Mehler  wrote:
> 
> Hello,
> 
> I have discovered what I believe is the issue after hearing back from
> Aquamail. And that is that android 7 which I'm running 7.0 that is,
> only supports up to the p256 ecc curve. This brings up a question to
> users of letsencrypt, when you revoke a certificate does it take it
> out on the usage as well? I've got one domain that says i've issued to
> many certificates for it and no more can be issued, thought I was
> using the staging server. I'd like to get those certs off the
> letsencrypt servers so I can make a new one using the p256 curve. Does
> anyone know if this is doable? Using acme.sh I tried --revoke which
> revoked one cert but letsencrypt still would not let me issue another.
> 
> Thanks.
> Dave.
> 
> 
> On 7/30/18, Aki Tuomi  wrote:
>> I don't know how to get both RSA and ECC cert from letsencrypt.
>> 
>> Aki
>> 
>>> On 30 July 2018 at 20:43 David Mehler  wrote:
>>> 
>>> 
>>> Hello,
>>> 
>>> What acme implementation do you use for your letsencrypt certificates?
>>> If it's acme.sh how do you get both rsa and ecc certificates? What
>>> configuration options are you using in your configuration of services
>>> to allow access to both rsa and ecc?
>>> 
>>> Thanks.
>>> Dave.
>>> 
>>> 
>>> On 7/30/18, David Mehler  wrote:
 Hello,
 
 The client in question is the latest version of AquaMail running on
 android.
 
 Thanks.
 Dave.
 
 
 On 7/30/18, Aki Tuomi  wrote:
> You should, in practice, enable both. This gives best client
> compability.
> It
> is possible you have clients that cannot understand ECC certificates?
> You
> can use ssl_alt_cert to provide RSA cert too.
> 
> Aki
> 
>> On 30 July 2018 at 20:05 David Mehler  wrote:
>> 
>> 
>> Hi,
>> 
>> Thanks, good news is that worked. Bad news is it all looks good which
>> means I do not know hwhy my remote clients can't get their email,
>> looked like from the logs it was that.
>> 
>> Would 143 be better or 993 for the external clients?
>> 
>> Thanks.
>> Dave.
>> 
>> 
>> On 7/30/18, Aki Tuomi  wrote:
>>> 
 On 30 July 2018 at 19:16 David Mehler 
 wrote:
 
 
 Hello,
 
 Does dovecot 2.3.x have any issues recognizing or using
 certificates
 that are ECC and wildcard? I'm trying to switch my letsencrypt
 implementation from acme-client which does not support either of
 those
 capabilities to acme.sh which does. Since then external clients
 checking their email has not worked. A manual telnet to
 mail.example.com 993 gives a connected message but then nothing no
 greeting or capabilities.
 
 The certificate is for example.com with an alt name of
 *.example.com
 if that's not right let me know, i'm not sure about that one,
 connecting to the web sites of these pages seems noticeably
 slower,
 I'm wondering if both of these issues aren't key related?
 
 Thanks.
 Dave.
>>> 
>>> These both should be fine.
>>> 
>>> Port 993 is TLS encrypted, you should use openssl s_client -connect
>>> server:993
>>> 
>>> Aki
>>> 
> 
 
>> 

Re: dovecot 2.3.x, ECC and wildcard certificates, any issues

[David Mehler]

Hello,

I have discovered what I believe is the issue after hearing back from
Aquamail. And that is that android 7 which I'm running 7.0 that is,
only supports up to the p256 ecc curve. This brings up a question to
users of letsencrypt, when you revoke a certificate does it take it
out on the usage as well? I've got one domain that says i've issued to
many certificates for it and no more can be issued, thought I was
using the staging server. I'd like to get those certs off the
letsencrypt servers so I can make a new one using the p256 curve. Does
anyone know if this is doable? Using acme.sh I tried --revoke which
revoked one cert but letsencrypt still would not let me issue another.

Thanks.
Dave.


On 7/30/18, Aki Tuomi  wrote:
> I don't know how to get both RSA and ECC cert from letsencrypt.
>
> Aki
>
>> On 30 July 2018 at 20:43 David Mehler  wrote:
>>
>>
>> Hello,
>>
>> What acme implementation do you use for your letsencrypt certificates?
>> If it's acme.sh how do you get both rsa and ecc certificates? What
>> configuration options are you using in your configuration of services
>> to allow access to both rsa and ecc?
>>
>> Thanks.
>> Dave.
>>
>>
>> On 7/30/18, David Mehler  wrote:
>> > Hello,
>> >
>> > The client in question is the latest version of AquaMail running on
>> > android.
>> >
>> > Thanks.
>> > Dave.
>> >
>> >
>> > On 7/30/18, Aki Tuomi  wrote:
>> >> You should, in practice, enable both. This gives best client
>> >> compability.
>> >> It
>> >> is possible you have clients that cannot understand ECC certificates?
>> >> You
>> >> can use ssl_alt_cert to provide RSA cert too.
>> >>
>> >> Aki
>> >>
>> >>> On 30 July 2018 at 20:05 David Mehler  wrote:
>> >>>
>> >>>
>> >>> Hi,
>> >>>
>> >>> Thanks, good news is that worked. Bad news is it all looks good which
>> >>> means I do not know hwhy my remote clients can't get their email,
>> >>> looked like from the logs it was that.
>> >>>
>> >>> Would 143 be better or 993 for the external clients?
>> >>>
>> >>> Thanks.
>> >>> Dave.
>> >>>
>> >>>
>> >>> On 7/30/18, Aki Tuomi  wrote:
>> >>> >
>> >>> >> On 30 July 2018 at 19:16 David Mehler 
>> >>> >> wrote:
>> >>> >>
>> >>> >>
>> >>> >> Hello,
>> >>> >>
>> >>> >> Does dovecot 2.3.x have any issues recognizing or using
>> >>> >> certificates
>> >>> >> that are ECC and wildcard? I'm trying to switch my letsencrypt
>> >>> >> implementation from acme-client which does not support either of
>> >>> >> those
>> >>> >> capabilities to acme.sh which does. Since then external clients
>> >>> >> checking their email has not worked. A manual telnet to
>> >>> >> mail.example.com 993 gives a connected message but then nothing no
>> >>> >> greeting or capabilities.
>> >>> >>
>> >>> >> The certificate is for example.com with an alt name of
>> >>> >> *.example.com
>> >>> >> if that's not right let me know, i'm not sure about that one,
>> >>> >> connecting to the web sites of these pages seems noticeably
>> >>> >> slower,
>> >>> >> I'm wondering if both of these issues aren't key related?
>> >>> >>
>> >>> >> Thanks.
>> >>> >> Dave.
>> >>> >
>> >>> > These both should be fine.
>> >>> >
>> >>> > Port 993 is TLS encrypted, you should use openssl s_client -connect
>> >>> > server:993
>> >>> >
>> >>> > Aki
>> >>> >
>> >>
>> >
>

2.3.2.1 - ssl_alt_key revealed with dovecot -n

[ѽ҉ᶬḳ℠]

Seems like a minor cosmetic bug with [ dovecot -n ]

ssl_alt_key = 

Re: 2.3.2.1 - EC keys suppport?

[ѽ҉ᶬḳ℠]

 I did some local testing and it seems that you are using a curve
 that is not acceptable for openssl as a server key.
 I tested with openssl s_server -cert ec-cert.pem -key ec-key.pem
 -port 
 using cert generated with brainpool. Everything works if I use
 prime256v1 or secp521r1. This is a limitation in OpenSSL and not
 something we can really do anything about.
 Aki Tuomi
 Open-Xchange Oy
>>> Which openssl version you are using? This end it is OpenSSL 1.1.0h.
>>> There are no issues creating private keys, issuing csr, signing certs
>>> with that particular curve. Printing certs and verifying certs against
>>> keys is panning out too, comparing md5 hashes also no errors. So why
>>> would openssl not accept (limit) keys is has generated and verified with
>>> no error?
>>>
>>>
>> try
>>
>> openssl s_server -cert /path/to/cert -key /path/to/key -port 
>>
>> openssl s_client -connect localhost:
>>
> Uhum, I see now. What a strange thing (bug?) openssl is doing. Thank you
> for valuable time/effort having debug this. Seems I have to start the CA
> all over...

Perhaps for whose interested - IETF RFC 7027 specifies for TLS use:

[ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ]

And thus t1 would not work anyway. However, having tested r1 the result
was just the same.

A tcpdump during the openssl test [ s_server | s_client ] then revealed
(TLSv1.2 Record Layer: Handshake Protocol: Client Hello) :

Extension: supported_groups (len=10)
    Type: supported_groups (10)
    Length: 10
    Supported Groups List Length: 8
    Supported Groups (4 groups)
    Supported Group: x25519 (0x001d)
    Supported Group: secp256r1 (0x0017)
    Supported Group: secp521r1 (0x0019)
    Supported Group: secp384r1 (0x0018)

Apparently [ brainpool ] would apparently not fit into any of those
groups. Perhaps a bug in OpenSSL 1.1.0h thus.

[SIEVE] pipe :copy to external program with arguments

[spamvoll]

Hi all,

quick questions about sieve pipe:
I want to pipe spam messages to an external program with additional
parameters

my spamlearn.sieve script:

require ["vnd.dovecot.pipe", "copy", "imapsieve"];
pipe :copy "mybin" ["-h 127.0.0.1:4" , "markspam"];

I also tried:
pipe :copy "mybin" ["-h 127.0.0.1:4 markspam"];
pipe :copy "mybin" ["-h 127.0.0.1:4"] ["markspam"];
pipe :copy :args ["-h 127.0.0.1:4 markspam"] "mybin" ;

It never executes correct, it always ends with:
Error: sieve: Execution of script /my/path/to/spamlearn.sieve failed

So whats the correct syntax ?

What works is a single argument:
pipe :copy "myscript" ["markspam"];

Dovecot Version 2.3.2.1

Doveadm protocol; dovecot v2.2.10

[David White]

Hi there,
Just wondering what is considered current best practice for managing dovecot?

The options I see are:

Doveadm binary
Doveadm protocol via socket
Doveadm http protocol

I’m currently on v2.2.10 and it appears the doveadm protocol command set is 
limited to just the “mailbox” commands and the http protocol hasn’t been 
implemented.

Is the doveadm http protocol still experimental in v2.3.2?

Thanks,

David White
ISP Engineer

Trustpower

T 021 223 6208
E david.wh...@trustpower.co.nz
Trustpower Limited, Private Bag 12023, Tauranga Mail Centre, Tauranga 3143



The contents of this email and any attachments are confidential and may be 
privileged.  If you are not the intended recipient, you may not use, copy or 
disclose this email or its attachments.  Please notify the sender immediately 
by e-mail if you have received this e-mail in error and delete both emails from 
your system.  It is your responsibility to check this email and any attachments 
for viruses or other harmful code before opening or sending on.  Trustpower 
Limited and its subsidiaries (collectively, Trustpower) accepts no 
responsibility for any such virus or any effects of a virus on your systems or 
data.  Trustpower does not endorse anything in this email that is not related 
to its official business.

Please think of the environment before printing this email.

Re: Restricting SSL/TLS protocol versions on Dovecot 2.2.22

[Reio Remma]

On 30.07.2018 22:29, Aki Tuomi wrote:

On 30 July 2018 at 21:42 J Doe  wrote:




On Jul 29, 2018, at 6:02 PM, Alexander Dalloz  wrote:

Am 29.07.2018 um 21:02 schrieb J Doe:

Hello,
I have a question regarding SSL/TLS settings for Dovecot version 2.2.22.
In: 10-ssl.conf there are two parameters:
 ssl_protocols
 ssl_cipher_list
ssl_protocols is commented with “SSL protocol to use” and ssl_cipher_list is 
commented with “SSL ciphers to use”.
If I want to disable SSLv3, for example, do I need to use both parameters or 
will disabling SSLv3 ciphers in
ssl_cipher_list do the same thing ?
So is:
 ssl_cipher_list = !SSLv3
…equivalent to:
 ssl_protocols = !SSLv3
 ssl_cipher_list = !SSLv3


No. SSLv3 is not a cipher but a protocol.

"ssl_protocols = !SSLv2 !SSLv3" is what you want to specify.

For ciphers you could define by ssl_cipher_list see "openssl ciphers -v”

Hi Alexander and list,

I think there may be a discrepancy in the documentation.

On the wiki on the “Dovecot SSL Configuration” page [1] under the section “SSL 
security settings” it says:

 ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL

In the conf.d/10-ssl.conf it states:

 # SSL protocols to use
 #ssl_protocols = !SSLv2

 # SSL ciphers to use
 #ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL

My new question is:

 1. Are the SSL/TLS protocols to use and/or exclude specified in 
“ssl_protocols”, “ssl_cipher_list” or both ?


You can use SSLv2 ciphers with TLSv1.2 protocol, if enabled. ssl protocol 
defines which protocol(s) to support. ssl_cipher_list defines which cipher(s) 
to support. They are not the same thing.

Aki


I personally used https://www.ssllabs.com/ssltest/analyze.html when I 
set up my server to get green across the board for the web server and 
then used the same ciphers for Dovecot and confirmed the result with 
https://github.com/drwetter/testssl.sh


ssl_min_protocol = TLSv1 # New in Dovecot 2.3 iirc.
ssl_cipher_list = "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM 
EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 
EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW 
!3DES !MD5 !EXP !PSK !SRP !DSS !RC4 !SEED"

ssl_prefer_server_ciphers = yes

Good luck,
Reio

Re: Restricting SSL/TLS protocol versions on Dovecot 2.2.22

[Aki Tuomi]

> On 30 July 2018 at 21:42 J Doe  wrote:
> 
> 
> 
> > On Jul 29, 2018, at 6:02 PM, Alexander Dalloz  wrote:
> > 
> > Am 29.07.2018 um 21:02 schrieb J Doe:
> >> Hello,
> >> I have a question regarding SSL/TLS settings for Dovecot version 2.2.22.
> >> In: 10-ssl.conf there are two parameters:
> >> ssl_protocols
> >> ssl_cipher_list
> >> ssl_protocols is commented with “SSL protocol to use” and ssl_cipher_list 
> >> is commented with “SSL ciphers to use”.
> >> If I want to disable SSLv3, for example, do I need to use both parameters 
> >> or will disabling SSLv3 ciphers in
> >> ssl_cipher_list do the same thing ?
> >> So is:
> >> ssl_cipher_list = !SSLv3
> >> …equivalent to:
> >> ssl_protocols = !SSLv3
> >> ssl_cipher_list = !SSLv3
> > 
> > 
> > No. SSLv3 is not a cipher but a protocol.
> > 
> > "ssl_protocols = !SSLv2 !SSLv3" is what you want to specify.
> > 
> > For ciphers you could define by ssl_cipher_list see "openssl ciphers -v”
> 
> Hi Alexander and list,
> 
> I think there may be a discrepancy in the documentation.
> 
> On the wiki on the “Dovecot SSL Configuration” page [1] under the section 
> “SSL security settings” it says:
> 
> ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL
> 
> In the conf.d/10-ssl.conf it states:
> 
> # SSL protocols to use
> #ssl_protocols = !SSLv2
> 
> # SSL ciphers to use
> #ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL
> 
> My new question is:
> 
> 1. Are the SSL/TLS protocols to use and/or exclude specified in 
> “ssl_protocols”, “ssl_cipher_list” or both ?
> 

You can use SSLv2 ciphers with TLSv1.2 protocol, if enabled. ssl protocol 
defines which protocol(s) to support. ssl_cipher_list defines which cipher(s) 
to support. They are not the same thing.

Aki

> Thanks,
> 
> - J
> 
> Sources:
> [1]  See: https://wiki2.dovecot.org/SSL/DovecotConfiguration

Re: Restricting SSL/TLS protocol versions on Dovecot 2.2.22

[J Doe]

> On Jul 29, 2018, at 6:02 PM, Alexander Dalloz  wrote:
> 
> Am 29.07.2018 um 21:02 schrieb J Doe:
>> Hello,
>> I have a question regarding SSL/TLS settings for Dovecot version 2.2.22.
>> In: 10-ssl.conf there are two parameters:
>> ssl_protocols
>> ssl_cipher_list
>> ssl_protocols is commented with “SSL protocol to use” and ssl_cipher_list is 
>> commented with “SSL ciphers to use”.
>> If I want to disable SSLv3, for example, do I need to use both parameters or 
>> will disabling SSLv3 ciphers in
>> ssl_cipher_list do the same thing ?
>> So is:
>> ssl_cipher_list = !SSLv3
>> …equivalent to:
>> ssl_protocols = !SSLv3
>> ssl_cipher_list = !SSLv3
> 
> 
> No. SSLv3 is not a cipher but a protocol.
> 
> "ssl_protocols = !SSLv2 !SSLv3" is what you want to specify.
> 
> For ciphers you could define by ssl_cipher_list see "openssl ciphers -v”

Hi Alexander and list,

I think there may be a discrepancy in the documentation.

On the wiki on the “Dovecot SSL Configuration” page [1] under the section “SSL 
security settings” it says:

ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL

In the conf.d/10-ssl.conf it states:

# SSL protocols to use
#ssl_protocols = !SSLv2

# SSL ciphers to use
#ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL

My new question is:

1. Are the SSL/TLS protocols to use and/or exclude specified in 
“ssl_protocols”, “ssl_cipher_list” or both ?

Thanks,

- J

Sources:
[1]  See: https://wiki2.dovecot.org/SSL/DovecotConfiguration

Re: 2.3.2.1 - EC keys suppport?

[ѽ҉ᶬḳ℠]

>>
>>> I did some local testing and it seems that you are using a curve
>>> that is not acceptable for openssl as a server key.
>>> I tested with openssl s_server -cert ec-cert.pem -key ec-key.pem
>>> -port 
>>> using cert generated with brainpool. Everything works if I use
>>> prime256v1 or secp521r1. This is a limitation in OpenSSL and not
>>> something we can really do anything about.
>>> Aki Tuomi
>>> Open-Xchange Oy
>> Which openssl version you are using? This end it is OpenSSL 1.1.0h.
>> There are no issues creating private keys, issuing csr, signing certs
>> with that particular curve. Printing certs and verifying certs against
>> keys is panning out too, comparing md5 hashes also no errors. So why
>> would openssl not accept (limit) keys is has generated and verified with
>> no error?
>>
>>
> try
>
> openssl s_server -cert /path/to/cert -key /path/to/key -port 
>
> openssl s_client -connect localhost:
>

Uhum, I see now. What a strange thing (bug?) openssl is doing. Thank you
for valuable time/effort having debug this. Seems I have to start the CA
all over...

Re: 2.3.2.1 - EC keys suppport?

[Aki Tuomi]

 
 
  
   
  
  
   
On 30 July 2018 at 21:00 ѽ҉ᶬḳ℠ <
v...@gmx.net> wrote:
   
   

   
   

   
   

   
   

 I did some local testing and it seems that you are using a curve that is not acceptable for openssl as a server key.

   
   

 I tested with openssl s_server -cert ec-cert.pem -key ec-key.pem -port 

   
   

 using cert generated with brainpool. Everything works if I use prime256v1 or secp521r1. This is a limitation in OpenSSL and not something we can really do anything about.

   
   

 Aki Tuomi


 Open-Xchange Oy

   
   
Which openssl version you are using? This end it is OpenSSL 1.1.0h.
   
   
There are no issues creating private keys, issuing csr, signing certs
   
   
with that particular curve. Printing certs and verifying certs against
   
   
keys is panning out too, comparing md5 hashes also no errors. So why
   
   
would openssl not accept (limit) keys is has generated and verified with
   
   
no error?
   
   

   
   
[ openssl ecparam -list_curves ]
   
   
  secp112r1 : SECG/WTLS curve over a 112 bit prime field
   
   
  secp112r2 : SECG curve over a 112 bit prime field
   
   
  secp128r1 : SECG curve over a 128 bit prime field
   
   
  secp128r2 : SECG curve over a 128 bit prime field
   
   
  secp160k1 : SECG curve over a 160 bit prime field
   
   
  secp160r1 : SECG curve over a 160 bit prime field
   
   
  secp160r2 : SECG/WTLS curve over a 160 bit prime field
   
   
  secp192k1 : SECG curve over a 192 bit prime field
   
   
  secp224k1 : SECG curve over a 224 bit prime field
   
   
  secp224r1 : NIST/SECG curve over a 224 bit prime field
   
   
  secp256k1 : SECG curve over a 256 bit prime field
   
   
  secp384r1 : NIST/SECG curve over a 384 bit prime field
   
   
  secp521r1 : NIST/SECG curve over a 521 bit prime field
   
   
  prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
   
   
  prime192v2: X9.62 curve over a 192 bit prime field
   
   
  prime192v3: X9.62 curve over a 192 bit prime field
   
   
  prime239v1: X9.62 curve over a 239 bit prime field
   
   
  prime239v2: X9.62 curve over a 239 bit prime field
   
   
  prime239v3: X9.62 curve over a 239 bit prime field
   
   
  prime256v1: X9.62/SECG curve over a 256 bit prime field
   
   
  sect113r1 : SECG curve over a 113 bit binary field
   
   
  sect113r2 : SECG curve over a 113 bit binary field
   
   
  sect131r1 : SECG/WTLS curve over a 131 bit binary field
   
   
  sect131r2 : SECG curve over a 131 bit binary field
   
   
  sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
   
   
  sect163r1 : SECG curve over a 163 bit binary field
   
   
  sect163r2 : NIST/SECG curve over a 163 bit binary field
   
   
  sect193r1 : SECG curve over a 193 bit binary field
   
   
  sect193r2 : SECG curve over a 193 bit binary field
   
   
  sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
   
   
  sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
   
   
  sect239k1 : SECG curve over a 239 bit binary field
   
   
  sect283k1 : NIST/SECG curve over a 283 bit binary field
   
   
  sect283r1 : NIST/SECG curve over a 283 bit binary field
   
   
  sect409k1 : NIST/SECG curve over a 409 bit binary field
   
   
  sect409r1 : NIST/SECG curve over a 409 bit binary field
   
   
  sect571k1 : NIST/SECG curve over a 571 bit binary field
   
   
  sect571r1 : NIST/SECG curve over a 571 bit binary field
   
   
  c2pnb163v1: X9.62 curve over a 163 bit binary field
   
   
  c2pnb163v2: X9.62 curve over a 163 bit binary field
   
   
  c2pnb163v3: X9.62 curve over a 163 bit binary field
   
   
  c2pnb176v1: X9.62 curve over a 176 bit binary field
   
   
  c2tnb191v1: X9.62 curve over a 191 bit binary field
   
   
  c2tnb191v2: X9.62 curve over a 191 bit binary field
   
   
  c2tnb191v3: X9.62 curve over a 191 bit binary field
   
   
  c2pnb208w1: X9.62 curve over a 208 bit binary field
   
   
  c2tnb239v1: X9.62 curve over a 239 bit binary field
   
   
  c2tnb239v2: X9.62 curve over a 239 bit binary field
   
   
  c2tnb239v3: X9.62 curve over a 239 bit binary field
   
   
  c2pnb272w1: X9.62 curve over a 272 bit binary field
   
   
  c2pnb304w1: X9.62 curve over a 304 bit binary field
   
   
  c2tnb359v1: X9.62 curve over a 359 bit binary field
   
   
  c2pnb368w1: X9.62 curve over a 368 bit binary field
   
   
  c2tnb431r1: X9.62 curve over a 431 bit binary field
   
   
  wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
   
   
  wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
   
   
  wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
   
   
  wap-wsg-i

Re: 2.3.2.1 - EC keys suppport?

[ѽ҉ᶬḳ℠]

>> I did some local testing and it seems that you are using a curve that is not 
>> acceptable for openssl as a server key.
>>
>> I tested with openssl s_server -cert ec-cert.pem -key ec-key.pem -port 
>>
>> using cert generated with brainpool. Everything works if I use prime256v1 or 
>> secp521r1. This is a limitation in OpenSSL and not something we can really 
>> do anything about.
>>
>> Aki Tuomi
>> Open-Xchange Oy
> Which openssl version you are using? This end it is OpenSSL 1.1.0h.
> There are no issues creating private keys, issuing csr, signing certs
> with that particular curve. Printing certs and verifying certs against
> keys is panning out too, comparing md5 hashes also no errors. So why
> would openssl not accept (limit) keys is has generated and verified with
> no error?
>
>

Ran both certificate types with [ openssl s_server -cert ec.cert.pem
-key ec.key.pem -port  ] and [ openssl s_server -cert rsa.cert.pem
-key rsa.key.pem -port  ] and both with the output:

Using default temp DH parameters
ACCEPT

Which would indicate this not being caused by openssl.

Re: 2.3.2.1 - EC keys suppport?

[ѽ҉ᶬḳ℠]

> I did some local testing and it seems that you are using a curve that is not 
> acceptable for openssl as a server key.
>
> I tested with openssl s_server -cert ec-cert.pem -key ec-key.pem -port 
>
> using cert generated with brainpool. Everything works if I use prime256v1 or 
> secp521r1. This is a limitation in OpenSSL and not something we can really do 
> anything about.
>
> Aki Tuomi
> Open-Xchange Oy

Which openssl version you are using? This end it is OpenSSL 1.1.0h.
There are no issues creating private keys, issuing csr, signing certs
with that particular curve. Printing certs and verifying certs against
keys is panning out too, comparing md5 hashes also no errors. So why
would openssl not accept (limit) keys is has generated and verified with
no error?

[ openssl ecparam -list_curves ]
  secp112r1 : SECG/WTLS curve over a 112 bit prime field
  secp112r2 : SECG curve over a 112 bit prime field
  secp128r1 : SECG curve over a 128 bit prime field
  secp128r2 : SECG curve over a 128 bit prime field
  secp160k1 : SECG curve over a 160 bit prime field
  secp160r1 : SECG curve over a 160 bit prime field
  secp160r2 : SECG/WTLS curve over a 160 bit prime field
  secp192k1 : SECG curve over a 192 bit prime field
  secp224k1 : SECG curve over a 224 bit prime field
  secp224r1 : NIST/SECG curve over a 224 bit prime field
  secp256k1 : SECG curve over a 256 bit prime field
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
  prime192v2: X9.62 curve over a 192 bit prime field
  prime192v3: X9.62 curve over a 192 bit prime field
  prime239v1: X9.62 curve over a 239 bit prime field
  prime239v2: X9.62 curve over a 239 bit prime field
  prime239v3: X9.62 curve over a 239 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field
  sect113r1 : SECG curve over a 113 bit binary field
  sect113r2 : SECG curve over a 113 bit binary field
  sect131r1 : SECG/WTLS curve over a 131 bit binary field
  sect131r2 : SECG curve over a 131 bit binary field
  sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
  sect163r1 : SECG curve over a 163 bit binary field
  sect163r2 : NIST/SECG curve over a 163 bit binary field
  sect193r1 : SECG curve over a 193 bit binary field
  sect193r2 : SECG curve over a 193 bit binary field
  sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
  sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
  sect239k1 : SECG curve over a 239 bit binary field
  sect283k1 : NIST/SECG curve over a 283 bit binary field
  sect283r1 : NIST/SECG curve over a 283 bit binary field
  sect409k1 : NIST/SECG curve over a 409 bit binary field
  sect409r1 : NIST/SECG curve over a 409 bit binary field
  sect571k1 : NIST/SECG curve over a 571 bit binary field
  sect571r1 : NIST/SECG curve over a 571 bit binary field
  c2pnb163v1: X9.62 curve over a 163 bit binary field
  c2pnb163v2: X9.62 curve over a 163 bit binary field
  c2pnb163v3: X9.62 curve over a 163 bit binary field
  c2pnb176v1: X9.62 curve over a 176 bit binary field
  c2tnb191v1: X9.62 curve over a 191 bit binary field
  c2tnb191v2: X9.62 curve over a 191 bit binary field
  c2tnb191v3: X9.62 curve over a 191 bit binary field
  c2pnb208w1: X9.62 curve over a 208 bit binary field
  c2tnb239v1: X9.62 curve over a 239 bit binary field
  c2tnb239v2: X9.62 curve over a 239 bit binary field
  c2tnb239v3: X9.62 curve over a 239 bit binary field
  c2pnb272w1: X9.62 curve over a 272 bit binary field
  c2pnb304w1: X9.62 curve over a 304 bit binary field
  c2tnb359v1: X9.62 curve over a 359 bit binary field
  c2pnb368w1: X9.62 curve over a 368 bit binary field
  c2tnb431r1: X9.62 curve over a 431 bit binary field
  wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
  wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
  wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
  wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
  wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
  wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
  wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
  wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
  wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
  wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
  wap-wsg-idm-ecid-wtls12: WTLS curve over a 224 bit prime field
  Oakley-EC2N-3:
    IPSec/IKE/Oakley curve #3 over a 155 bit binary field.
    Not suitable for ECDSA.
    Questionable extension field!
  Oakley-EC2N-4:
    IPSec/IKE/Oakley curve #4 over a 185 bit binary field.
    Not suitable for ECDSA.
    Questionable extension field!
  brainpoolP160r1: RFC 5639 curve over a 160 bit prime field
  brainpoolP160t1: RFC 5639 curve over a 160 bit prime field
  brainpoolP192r1: RFC 5639 curve o

Re: dovecot 2.3.x, ECC and wildcard certificates, any issues

[Felipe Gasper]

FWIW, it’s relatively straightforward to do this with my Perl ACME 
implementation, Net::ACME2.

You’ll get your first certificate order using one key, then request another 
certificate with the other key.

-FG

> On Jul 30, 2018, at 1:49 PM, Aki Tuomi  wrote:
> 
> I don't know how to get both RSA and ECC cert from letsencrypt.
> 
> Aki
> 
>> On 30 July 2018 at 20:43 David Mehler  wrote:
>> 
>> 
>> Hello,
>> 
>> What acme implementation do you use for your letsencrypt certificates?
>> If it's acme.sh how do you get both rsa and ecc certificates? What
>> configuration options are you using in your configuration of services
>> to allow access to both rsa and ecc?
>> 
>> Thanks.
>> Dave.
>> 
>> 
>> On 7/30/18, David Mehler  wrote:
>>> Hello,
>>> 
>>> The client in question is the latest version of AquaMail running on
>>> android.
>>> 
>>> Thanks.
>>> Dave.
>>> 
>>> 
>>> On 7/30/18, Aki Tuomi  wrote:
 You should, in practice, enable both. This gives best client compability.
 It
 is possible you have clients that cannot understand ECC certificates? You
 can use ssl_alt_cert to provide RSA cert too.
 
 Aki
 
> On 30 July 2018 at 20:05 David Mehler  wrote:
> 
> 
> Hi,
> 
> Thanks, good news is that worked. Bad news is it all looks good which
> means I do not know hwhy my remote clients can't get their email,
> looked like from the logs it was that.
> 
> Would 143 be better or 993 for the external clients?
> 
> Thanks.
> Dave.
> 
> 
> On 7/30/18, Aki Tuomi  wrote:
>> 
>>> On 30 July 2018 at 19:16 David Mehler  wrote:
>>> 
>>> 
>>> Hello,
>>> 
>>> Does dovecot 2.3.x have any issues recognizing or using certificates
>>> that are ECC and wildcard? I'm trying to switch my letsencrypt
>>> implementation from acme-client which does not support either of
>>> those
>>> capabilities to acme.sh which does. Since then external clients
>>> checking their email has not worked. A manual telnet to
>>> mail.example.com 993 gives a connected message but then nothing no
>>> greeting or capabilities.
>>> 
>>> The certificate is for example.com with an alt name of *.example.com
>>> if that's not right let me know, i'm not sure about that one,
>>> connecting to the web sites of these pages seems noticeably slower,
>>> I'm wondering if both of these issues aren't key related?
>>> 
>>> Thanks.
>>> Dave.
>> 
>> These both should be fine.
>> 
>> Port 993 is TLS encrypted, you should use openssl s_client -connect
>> server:993
>> 
>> Aki
>> 
 
>>> 

Re: dovecot 2.3.x, ECC and wildcard certificates, any issues

[Aki Tuomi]

I don't know how to get both RSA and ECC cert from letsencrypt.

Aki

> On 30 July 2018 at 20:43 David Mehler  wrote:
> 
> 
> Hello,
> 
> What acme implementation do you use for your letsencrypt certificates?
> If it's acme.sh how do you get both rsa and ecc certificates? What
> configuration options are you using in your configuration of services
> to allow access to both rsa and ecc?
> 
> Thanks.
> Dave.
> 
> 
> On 7/30/18, David Mehler  wrote:
> > Hello,
> >
> > The client in question is the latest version of AquaMail running on
> > android.
> >
> > Thanks.
> > Dave.
> >
> >
> > On 7/30/18, Aki Tuomi  wrote:
> >> You should, in practice, enable both. This gives best client compability.
> >> It
> >> is possible you have clients that cannot understand ECC certificates? You
> >> can use ssl_alt_cert to provide RSA cert too.
> >>
> >> Aki
> >>
> >>> On 30 July 2018 at 20:05 David Mehler  wrote:
> >>>
> >>>
> >>> Hi,
> >>>
> >>> Thanks, good news is that worked. Bad news is it all looks good which
> >>> means I do not know hwhy my remote clients can't get their email,
> >>> looked like from the logs it was that.
> >>>
> >>> Would 143 be better or 993 for the external clients?
> >>>
> >>> Thanks.
> >>> Dave.
> >>>
> >>>
> >>> On 7/30/18, Aki Tuomi  wrote:
> >>> >
> >>> >> On 30 July 2018 at 19:16 David Mehler  wrote:
> >>> >>
> >>> >>
> >>> >> Hello,
> >>> >>
> >>> >> Does dovecot 2.3.x have any issues recognizing or using certificates
> >>> >> that are ECC and wildcard? I'm trying to switch my letsencrypt
> >>> >> implementation from acme-client which does not support either of
> >>> >> those
> >>> >> capabilities to acme.sh which does. Since then external clients
> >>> >> checking their email has not worked. A manual telnet to
> >>> >> mail.example.com 993 gives a connected message but then nothing no
> >>> >> greeting or capabilities.
> >>> >>
> >>> >> The certificate is for example.com with an alt name of *.example.com
> >>> >> if that's not right let me know, i'm not sure about that one,
> >>> >> connecting to the web sites of these pages seems noticeably slower,
> >>> >> I'm wondering if both of these issues aren't key related?
> >>> >>
> >>> >> Thanks.
> >>> >> Dave.
> >>> >
> >>> > These both should be fine.
> >>> >
> >>> > Port 993 is TLS encrypted, you should use openssl s_client -connect
> >>> > server:993
> >>> >
> >>> > Aki
> >>> >
> >>
> >

Re: 2.3.2.1 - EC keys suppport?

[Aki Tuomi]

> On 30 July 2018 at 20:37 ѽ҉ᶬḳ℠  wrote:
> 
> 
> 
> >>> facing [ no shared cipher ] error with EC private keys.
> >> the client connecting to your instance has to support ecdsa
> >>
> >>
> > It does - Thunderbird 60.0b10 (64-bit)
> >
> > [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
> >
> > It seems there is a difference between the private key (rsa vs. ecc ->
> > SSL_CTX?) used for the certificate signing request and the signed
> > certificate.
> >
> > The csr created from a private key with [ openssl genpkey -algorithm RSA
> > ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
> >
> > But as stated in the initial message it does not work if the private key
> > for the csr is generated with [ openssl ecparam -name brainpoolP512t1
> > -genkey ].
> >
> >
>  Can you try, with your ECC cert,
> 
>  openssl s_client -connect server:143 -starttls imap
> 
>  and paste result?
> 
> >>> This is for the certificate where the csr is generated with an EC
> >>> private key and the [ no shared cipher ] error:
> >>>
> >>> CONNECTED(0003)
> >>> write:errno=0
> >>> ---
> >>> no peer certificate available
> >>> ---
> >>> No client certificate CA names sent
> >>> ---
> >>> SSL handshake has read 309 bytes and written 202 bytes
> >>> Verification: OK
> >>> ---
> >>> New, (NONE), Cipher is (NONE)
> >>> Secure Renegotiation IS NOT supported
> >>> Compression: NONE
> >>> Expansion: NONE
> >>> No ALPN negotiated
> >>> SSL-Session:
> >>>     Protocol  : TLSv1.2
> >>>     Cipher    : 
> >>>     Session-ID:
> >>>     Session-ID-ctx:
> >>>     Master-Key:
> >>>     PSK identity: None
> >>>     PSK identity hint: None
> >>>     SRP username: None
> >>>     Start Time: 1532969474
> >>>     Timeout   : 7200 (sec)
> >>>     Verify return code: 0 (ok)
> >>>     Extended master secret: no
> >>>
> >>> ---
> >>>
> >>> and this for the certificate where the csr is generated with a RSA
> >>> private key:
> >>>
> >>> CONNECTED(0003)
> >>> depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server
> >>> foo.bar Mail IMAP
> >>> verify error:num=20:unable to get local issuer certificate
> >>> verify return:1
> >>> depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server
> >>> foo.bar Mail IMAP
> >>> verify error:num=21:unable to verify the first certificate
> >>> verify return:1
> >>> ---
> >>> Certificate chain
> >>>  0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP
> >>>    i:/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
> >>> ---
> >>> Server certificate
> >>> -BEGIN CERTIFICATE-
> >>> [ truncated ]
> >>> -END CERTIFICATE-
> >>> subject=/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP
> >>> issuer=/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
> >>> ---
> >>> No client certificate CA names sent
> >>> Peer signing digest: SHA512
> >>> Server Temp Key: X25519, 253 bits
> >>> ---
> >>> SSL handshake has read 2361 bytes and written 295 bytes
> >>> Verification error: unable to verify the first certificate
> >>> ---
> >>> New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> >>> Server public key is 4096 bit
> >>> Secure Renegotiation IS supported
> >>> Compression: NONE
> >>> Expansion: NONE
> >>> No ALPN negotiated
> >>> SSL-Session:
> >>>     Protocol  : TLSv1.2
> >>>     Cipher    : ECDHE-RSA-AES256-GCM-SHA384
> >>>     Session-ID:
> >>> C23E6478F4C6372F2A524504031B32EDC9FDCAA343AE5017A09E47C5E7B60DD6
> >>>     Session-ID-ctx:
> >>>     Master-Key: [ obfuscated ]
> >>>     PSK identity: None
> >>>     PSK identity hint: None
> >>>     SRP username: None
> >>>     Start Time: 1532969755
> >>>     Timeout   : 7200 (sec)
> >>>     Verify return code: 21 (unable to verify the first certificate)
> >>>     Extended master secret: yes
> >>> ---
> >>> . OK Pre-login capabilities listed, post-login capabilities have more.
> >>>
> >>>
> >>>
> >> Can you configure ssl_cipher_list = ALL and try again? Also, can you send 
> >> the *PUBLIC* part of the certificate?
> >>
> > [ ssl_cipher_list = ALL ] set/applied
> >
> > This is for the certificate where the csr is generated with an EC private 
> > key and the [ no shared cipher ] error:
> >
> > CONNECTED(0003)
> > write:errno=0
> > ---
> > no peer certificate available
> > ---
> > No client certificate CA names sent
> > ---
> > SSL handshake has read 309 bytes and written 202 bytes
> > Verification: OK
> > ---
> > New, (NONE), Cipher is (NONE)
> > Secure Renegotiation IS NOT supported
> > Compression: NONE
> > Expansion: NONE
> > No ALPN negotiated
> > SSL-Session:
> >     Protocol  : TLSv1.2
> >     Cipher    : 
> >     Session-ID:
> >     Session-ID-ctx:
> >     Master-Key:
> >     PSK identity: None
> >     PSK identity hint: None
> >     SRP username: None
> >     Start Time: 1532970888
> >     Timeout   : 7200 (sec)
> >     Verify return code: 0 (ok)
> >     Extended master secret

Re: dovecot 2.3.x, ECC and wildcard certificates, any issues

[David Mehler]

Hello,

What acme implementation do you use for your letsencrypt certificates?
If it's acme.sh how do you get both rsa and ecc certificates? What
configuration options are you using in your configuration of services
to allow access to both rsa and ecc?

Thanks.
Dave.


On 7/30/18, David Mehler  wrote:
> Hello,
>
> The client in question is the latest version of AquaMail running on
> android.
>
> Thanks.
> Dave.
>
>
> On 7/30/18, Aki Tuomi  wrote:
>> You should, in practice, enable both. This gives best client compability.
>> It
>> is possible you have clients that cannot understand ECC certificates? You
>> can use ssl_alt_cert to provide RSA cert too.
>>
>> Aki
>>
>>> On 30 July 2018 at 20:05 David Mehler  wrote:
>>>
>>>
>>> Hi,
>>>
>>> Thanks, good news is that worked. Bad news is it all looks good which
>>> means I do not know hwhy my remote clients can't get their email,
>>> looked like from the logs it was that.
>>>
>>> Would 143 be better or 993 for the external clients?
>>>
>>> Thanks.
>>> Dave.
>>>
>>>
>>> On 7/30/18, Aki Tuomi  wrote:
>>> >
>>> >> On 30 July 2018 at 19:16 David Mehler  wrote:
>>> >>
>>> >>
>>> >> Hello,
>>> >>
>>> >> Does dovecot 2.3.x have any issues recognizing or using certificates
>>> >> that are ECC and wildcard? I'm trying to switch my letsencrypt
>>> >> implementation from acme-client which does not support either of
>>> >> those
>>> >> capabilities to acme.sh which does. Since then external clients
>>> >> checking their email has not worked. A manual telnet to
>>> >> mail.example.com 993 gives a connected message but then nothing no
>>> >> greeting or capabilities.
>>> >>
>>> >> The certificate is for example.com with an alt name of *.example.com
>>> >> if that's not right let me know, i'm not sure about that one,
>>> >> connecting to the web sites of these pages seems noticeably slower,
>>> >> I'm wondering if both of these issues aren't key related?
>>> >>
>>> >> Thanks.
>>> >> Dave.
>>> >
>>> > These both should be fine.
>>> >
>>> > Port 993 is TLS encrypted, you should use openssl s_client -connect
>>> > server:993
>>> >
>>> > Aki
>>> >
>>
>

Re: 2.3.2.1 - EC keys suppport?

[ѽ҉ᶬḳ℠]

>>> facing [ no shared cipher ] error with EC private keys.
>> the client connecting to your instance has to support ecdsa
>>
>>
> It does - Thunderbird 60.0b10 (64-bit)
>
> [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
>
> It seems there is a difference between the private key (rsa vs. ecc ->
> SSL_CTX?) used for the certificate signing request and the signed
> certificate.
>
> The csr created from a private key with [ openssl genpkey -algorithm RSA
> ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
>
> But as stated in the initial message it does not work if the private key
> for the csr is generated with [ openssl ecparam -name brainpoolP512t1
> -genkey ].
>
>
 Can you try, with your ECC cert,

 openssl s_client -connect server:143 -starttls imap

 and paste result?

>>> This is for the certificate where the csr is generated with an EC
>>> private key and the [ no shared cipher ] error:
>>>
>>> CONNECTED(0003)
>>> write:errno=0
>>> ---
>>> no peer certificate available
>>> ---
>>> No client certificate CA names sent
>>> ---
>>> SSL handshake has read 309 bytes and written 202 bytes
>>> Verification: OK
>>> ---
>>> New, (NONE), Cipher is (NONE)
>>> Secure Renegotiation IS NOT supported
>>> Compression: NONE
>>> Expansion: NONE
>>> No ALPN negotiated
>>> SSL-Session:
>>>     Protocol  : TLSv1.2
>>>     Cipher    : 
>>>     Session-ID:
>>>     Session-ID-ctx:
>>>     Master-Key:
>>>     PSK identity: None
>>>     PSK identity hint: None
>>>     SRP username: None
>>>     Start Time: 1532969474
>>>     Timeout   : 7200 (sec)
>>>     Verify return code: 0 (ok)
>>>     Extended master secret: no
>>>
>>> ---
>>>
>>> and this for the certificate where the csr is generated with a RSA
>>> private key:
>>>
>>> CONNECTED(0003)
>>> depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server
>>> foo.bar Mail IMAP
>>> verify error:num=20:unable to get local issuer certificate
>>> verify return:1
>>> depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server
>>> foo.bar Mail IMAP
>>> verify error:num=21:unable to verify the first certificate
>>> verify return:1
>>> ---
>>> Certificate chain
>>>  0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP
>>>    i:/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
>>> ---
>>> Server certificate
>>> -BEGIN CERTIFICATE-
>>> [ truncated ]
>>> -END CERTIFICATE-
>>> subject=/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP
>>> issuer=/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
>>> ---
>>> No client certificate CA names sent
>>> Peer signing digest: SHA512
>>> Server Temp Key: X25519, 253 bits
>>> ---
>>> SSL handshake has read 2361 bytes and written 295 bytes
>>> Verification error: unable to verify the first certificate
>>> ---
>>> New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
>>> Server public key is 4096 bit
>>> Secure Renegotiation IS supported
>>> Compression: NONE
>>> Expansion: NONE
>>> No ALPN negotiated
>>> SSL-Session:
>>>     Protocol  : TLSv1.2
>>>     Cipher    : ECDHE-RSA-AES256-GCM-SHA384
>>>     Session-ID:
>>> C23E6478F4C6372F2A524504031B32EDC9FDCAA343AE5017A09E47C5E7B60DD6
>>>     Session-ID-ctx:
>>>     Master-Key: [ obfuscated ]
>>>     PSK identity: None
>>>     PSK identity hint: None
>>>     SRP username: None
>>>     Start Time: 1532969755
>>>     Timeout   : 7200 (sec)
>>>     Verify return code: 21 (unable to verify the first certificate)
>>>     Extended master secret: yes
>>> ---
>>> . OK Pre-login capabilities listed, post-login capabilities have more.
>>>
>>>
>>>
>> Can you configure ssl_cipher_list = ALL and try again? Also, can you send 
>> the *PUBLIC* part of the certificate?
>>
> [ ssl_cipher_list = ALL ] set/applied
>
> This is for the certificate where the csr is generated with an EC private key 
> and the [ no shared cipher ] error:
>
> CONNECTED(0003)
> write:errno=0
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 309 bytes and written 202 bytes
> Verification: OK
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : 
>     Session-ID:
>     Session-ID-ctx:
>     Master-Key:
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     Start Time: 1532970888
>     Timeout   : 7200 (sec)
>     Verify return code: 0 (ok)
>     Extended master secret: no
>
> ---
>
> and this for the certificate where the csr is generated with a RSA
> private key:
>
> CONNECTED(0003)
> depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server
> foo.bar Mail IMAP
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN

Re: dovecot 2.3.x, ECC and wildcard certificates, any issues

[David Mehler]

Hello,

The client in question is the latest version of AquaMail running on android.

Thanks.
Dave.


On 7/30/18, Aki Tuomi  wrote:
> You should, in practice, enable both. This gives best client compability. It
> is possible you have clients that cannot understand ECC certificates? You
> can use ssl_alt_cert to provide RSA cert too.
>
> Aki
>
>> On 30 July 2018 at 20:05 David Mehler  wrote:
>>
>>
>> Hi,
>>
>> Thanks, good news is that worked. Bad news is it all looks good which
>> means I do not know hwhy my remote clients can't get their email,
>> looked like from the logs it was that.
>>
>> Would 143 be better or 993 for the external clients?
>>
>> Thanks.
>> Dave.
>>
>>
>> On 7/30/18, Aki Tuomi  wrote:
>> >
>> >> On 30 July 2018 at 19:16 David Mehler  wrote:
>> >>
>> >>
>> >> Hello,
>> >>
>> >> Does dovecot 2.3.x have any issues recognizing or using certificates
>> >> that are ECC and wildcard? I'm trying to switch my letsencrypt
>> >> implementation from acme-client which does not support either of those
>> >> capabilities to acme.sh which does. Since then external clients
>> >> checking their email has not worked. A manual telnet to
>> >> mail.example.com 993 gives a connected message but then nothing no
>> >> greeting or capabilities.
>> >>
>> >> The certificate is for example.com with an alt name of *.example.com
>> >> if that's not right let me know, i'm not sure about that one,
>> >> connecting to the web sites of these pages seems noticeably slower,
>> >> I'm wondering if both of these issues aren't key related?
>> >>
>> >> Thanks.
>> >> Dave.
>> >
>> > These both should be fine.
>> >
>> > Port 993 is TLS encrypted, you should use openssl s_client -connect
>> > server:993
>> >
>> > Aki
>> >
>

Re: 2.3.2.1 - EC keys suppport?

[ѽ҉ᶬḳ℠]

>> facing [ no shared cipher ] error with EC private keys.
> the client connecting to your instance has to support ecdsa
>
>
 It does - Thunderbird 60.0b10 (64-bit)

 [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]

 It seems there is a difference between the private key (rsa vs. ecc ->
 SSL_CTX?) used for the certificate signing request and the signed
 certificate.

 The csr created from a private key with [ openssl genpkey -algorithm RSA
 ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.

 But as stated in the initial message it does not work if the private key
 for the csr is generated with [ openssl ecparam -name brainpoolP512t1
 -genkey ].


>>> Can you try, with your ECC cert,
>>>
>>> openssl s_client -connect server:143 -starttls imap
>>>
>>> and paste result?
>>>
>> This is for the certificate where the csr is generated with an EC
>> private key and the [ no shared cipher ] error:
>>
>> CONNECTED(0003)
>> write:errno=0
>> ---
>> no peer certificate available
>> ---
>> No client certificate CA names sent
>> ---
>> SSL handshake has read 309 bytes and written 202 bytes
>> Verification: OK
>> ---
>> New, (NONE), Cipher is (NONE)
>> Secure Renegotiation IS NOT supported
>> Compression: NONE
>> Expansion: NONE
>> No ALPN negotiated
>> SSL-Session:
>>     Protocol  : TLSv1.2
>>     Cipher    : 
>>     Session-ID:
>>     Session-ID-ctx:
>>     Master-Key:
>>     PSK identity: None
>>     PSK identity hint: None
>>     SRP username: None
>>     Start Time: 1532969474
>>     Timeout   : 7200 (sec)
>>     Verify return code: 0 (ok)
>>     Extended master secret: no
>>
>> ---
>>
>> and this for the certificate where the csr is generated with a RSA
>> private key:
>>
>> CONNECTED(0003)
>> depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server
>> foo.bar Mail IMAP
>> verify error:num=20:unable to get local issuer certificate
>> verify return:1
>> depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server
>> foo.bar Mail IMAP
>> verify error:num=21:unable to verify the first certificate
>> verify return:1
>> ---
>> Certificate chain
>>  0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP
>>    i:/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
>> ---
>> Server certificate
>> -BEGIN CERTIFICATE-
>> [ truncated ]
>> -END CERTIFICATE-
>> subject=/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP
>> issuer=/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
>> ---
>> No client certificate CA names sent
>> Peer signing digest: SHA512
>> Server Temp Key: X25519, 253 bits
>> ---
>> SSL handshake has read 2361 bytes and written 295 bytes
>> Verification error: unable to verify the first certificate
>> ---
>> New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
>> Server public key is 4096 bit
>> Secure Renegotiation IS supported
>> Compression: NONE
>> Expansion: NONE
>> No ALPN negotiated
>> SSL-Session:
>>     Protocol  : TLSv1.2
>>     Cipher    : ECDHE-RSA-AES256-GCM-SHA384
>>     Session-ID:
>> C23E6478F4C6372F2A524504031B32EDC9FDCAA343AE5017A09E47C5E7B60DD6
>>     Session-ID-ctx:
>>     Master-Key: [ obfuscated ]
>>     PSK identity: None
>>     PSK identity hint: None
>>     SRP username: None
>>     Start Time: 1532969755
>>     Timeout   : 7200 (sec)
>>     Verify return code: 21 (unable to verify the first certificate)
>>     Extended master secret: yes
>> ---
>> . OK Pre-login capabilities listed, post-login capabilities have more.
>>
>>
>>
> Can you configure ssl_cipher_list = ALL and try again? Also, can you send the 
> *PUBLIC* part of the certificate?
>

[ ssl_cipher_list = ALL ] set/applied

This is for the certificate where the csr is generated with an EC private key 
and the [ no shared cipher ] error:

CONNECTED(0003)
write:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 309 bytes and written 202 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1532970888
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no

---

and this for the certificate where the csr is generated with a RSA
private key:

CONNECTED(0003)
depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server
foo.bar Mail IMAP
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server
foo.bar Mail IMAP
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP
   i:/C=00

Re: dovecot 2.3.x, ECC and wildcard certificates, any issues

[Aki Tuomi]

You should, in practice, enable both. This gives best client compability. It is 
possible you have clients that cannot understand ECC certificates? You can use 
ssl_alt_cert to provide RSA cert too.

Aki

> On 30 July 2018 at 20:05 David Mehler  wrote:
> 
> 
> Hi,
> 
> Thanks, good news is that worked. Bad news is it all looks good which
> means I do not know hwhy my remote clients can't get their email,
> looked like from the logs it was that.
> 
> Would 143 be better or 993 for the external clients?
> 
> Thanks.
> Dave.
> 
> 
> On 7/30/18, Aki Tuomi  wrote:
> >
> >> On 30 July 2018 at 19:16 David Mehler  wrote: 
> >>
> >>
> >> Hello,
> >>
> >> Does dovecot 2.3.x have any issues recognizing or using certificates
> >> that are ECC and wildcard? I'm trying to switch my letsencrypt
> >> implementation from acme-client which does not support either of those
> >> capabilities to acme.sh which does. Since then external clients
> >> checking their email has not worked. A manual telnet to
> >> mail.example.com 993 gives a connected message but then nothing no
> >> greeting or capabilities.
> >>
> >> The certificate is for example.com with an alt name of *.example.com
> >> if that's not right let me know, i'm not sure about that one,
> >> connecting to the web sites of these pages seems noticeably slower,
> >> I'm wondering if both of these issues aren't key related?
> >>
> >> Thanks.
> >> Dave.
> >
> > These both should be fine.
> >
> > Port 993 is TLS encrypted, you should use openssl s_client -connect
> > server:993
> >
> > Aki
> >

Re: dovecot 2.3.x, ECC and wildcard certificates, any issues

[David Mehler]

Hi,

Thanks, good news is that worked. Bad news is it all looks good which
means I do not know hwhy my remote clients can't get their email,
looked like from the logs it was that.

Would 143 be better or 993 for the external clients?

Thanks.
Dave.


On 7/30/18, Aki Tuomi  wrote:
>
>> On 30 July 2018 at 19:16 David Mehler  wrote:
>>
>>
>> Hello,
>>
>> Does dovecot 2.3.x have any issues recognizing or using certificates
>> that are ECC and wildcard? I'm trying to switch my letsencrypt
>> implementation from acme-client which does not support either of those
>> capabilities to acme.sh which does. Since then external clients
>> checking their email has not worked. A manual telnet to
>> mail.example.com 993 gives a connected message but then nothing no
>> greeting or capabilities.
>>
>> The certificate is for example.com with an alt name of *.example.com
>> if that's not right let me know, i'm not sure about that one,
>> connecting to the web sites of these pages seems noticeably slower,
>> I'm wondering if both of these issues aren't key related?
>>
>> Thanks.
>> Dave.
>
> These both should be fine.
>
> Port 993 is TLS encrypted, you should use openssl s_client -connect
> server:993
>
> Aki
>

Re: 2.3.2.1 - EC keys suppport?

[Aki Tuomi]

> On 30 July 2018 at 20:01 ѽ҉ᶬḳ℠  wrote:
> 
> 
> 
>  facing [ no shared cipher ] error with EC private keys.
> >>> the client connecting to your instance has to support ecdsa
> >>>
> >>>
> >> It does - Thunderbird 60.0b10 (64-bit)
> >>
> >> [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
> >>
> >> It seems there is a difference between the private key (rsa vs. ecc ->
> >> SSL_CTX?) used for the certificate signing request and the signed
> >> certificate.
> >>
> >> The csr created from a private key with [ openssl genpkey -algorithm RSA
> >> ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
> >>
> >> But as stated in the initial message it does not work if the private key
> >> for the csr is generated with [ openssl ecparam -name brainpoolP512t1
> >> -genkey ].
> >>
> >>
> > Can you try, with your ECC cert,
> >
> > openssl s_client -connect server:143 -starttls imap
> >
> > and paste result?
> >
> 
> This is for the certificate where the csr is generated with an EC
> private key and the [ no shared cipher ] error:
> 
> CONNECTED(0003)
> write:errno=0
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 309 bytes and written 202 bytes
> Verification: OK
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : 
>     Session-ID:
>     Session-ID-ctx:
>     Master-Key:
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     Start Time: 1532969474
>     Timeout   : 7200 (sec)
>     Verify return code: 0 (ok)
>     Extended master secret: no
> 
> ---
> 
> and this for the certificate where the csr is generated with a RSA
> private key:
> 
> CONNECTED(0003)
> depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server
> foo.bar Mail IMAP
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server
> foo.bar Mail IMAP
> verify error:num=21:unable to verify the first certificate
> verify return:1
> ---
> Certificate chain
>  0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP
>    i:/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> [ truncated ]
> -END CERTIFICATE-
> subject=/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP
> issuer=/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
> ---
> No client certificate CA names sent
> Peer signing digest: SHA512
> Server Temp Key: X25519, 253 bits
> ---
> SSL handshake has read 2361 bytes and written 295 bytes
> Verification error: unable to verify the first certificate
> ---
> New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> Server public key is 4096 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : ECDHE-RSA-AES256-GCM-SHA384
>     Session-ID:
> C23E6478F4C6372F2A524504031B32EDC9FDCAA343AE5017A09E47C5E7B60DD6
>     Session-ID-ctx:
>     Master-Key: [ obfuscated ]
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     Start Time: 1532969755
>     Timeout   : 7200 (sec)
>     Verify return code: 21 (unable to verify the first certificate)
>     Extended master secret: yes
> ---
> . OK Pre-login capabilities listed, post-login capabilities have more.
> 
> 
>

Can you configure ssl_cipher_list = ALL and try again? Also, can you send the 
*PUBLIC* part of the certificate?

Aki

Re: 2.3.2.1 - EC keys suppport?

[ѽ҉ᶬḳ℠]

 facing [ no shared cipher ] error with EC private keys.
>>> the client connecting to your instance has to support ecdsa
>>>
>>>
>> It does - Thunderbird 60.0b10 (64-bit)
>>
>> [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
>>
>> It seems there is a difference between the private key (rsa vs. ecc ->
>> SSL_CTX?) used for the certificate signing request and the signed
>> certificate.
>>
>> The csr created from a private key with [ openssl genpkey -algorithm RSA
>> ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
>>
>> But as stated in the initial message it does not work if the private key
>> for the csr is generated with [ openssl ecparam -name brainpoolP512t1
>> -genkey ].
>>
>>
> Can you try, with your ECC cert,
>
> openssl s_client -connect server:143 -starttls imap
>
> and paste result?
>

This is for the certificate where the csr is generated with an EC
private key and the [ no shared cipher ] error:

CONNECTED(0003)
write:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 309 bytes and written 202 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1532969474
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no

---

and this for the certificate where the csr is generated with a RSA
private key:

CONNECTED(0003)
depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server
foo.bar Mail IMAP
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = 00, ST = CH, L = DC, O = foo.bar, OU = mail, CN = Server
foo.bar Mail IMAP
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP
   i:/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
---
Server certificate
-BEGIN CERTIFICATE-
[ truncated ]
-END CERTIFICATE-
subject=/C=00/ST=CH/L=DC/O=foo.bar/OU=mail/CN=Server foo.bar Mail IMAP
issuer=/C=00/ST=CH/O=foo.bar/OU=Server/CN=IM Server foo.bar
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2361 bytes and written 295 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID:
C23E6478F4C6372F2A524504031B32EDC9FDCAA343AE5017A09E47C5E7B60DD6
    Session-ID-ctx:
    Master-Key: [ obfuscated ]
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1532969755
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: yes
---
. OK Pre-login capabilities listed, post-login capabilities have more.

Problems with Sieve and vnd.dovecot.pipe

[Haiko Hertes]

Hello all!

 

I have changed my mailserver from spamassasin and procmail to rspamd and
sieve. Rspamd is working, but with some sieve script I still have problems.

 

I have created a script to learn spam:

 

haiko@SERVERNAME:~$ sudo cat /var/vmail/sieve/global/learn-spam.sieve

require ["vnd.dovecot.pipe", "copy", "imapsieve"];

pipe :copy "rspamd-learn-spam.sh";

 

If I run sieve to use this script I get this:

 

haiko@SERVERNAME:~$ sudo sieve /var/vmail/sieve/global/learn-spam.sieve

sieve: vnd.dovecot.pipe: file not found

sieve: can't require vnd.dovecot.pipe

Speicherzugriffsfehler

 

I think, my configs are OK:

 

haiko@SERVERNAME:~$ doveconf -n

# 2.2.27 (c0f36b0): /etc/dovecot/dovecot.conf

# Pigeonhole version 0.4.16 (fed8554)

# OS: Linux 4.9.0-7-amd64 x86_64 Debian 9.5

auth_debug_passwords = yes

auth_mechanisms = plain login PLAIN LOGIN

auth_username_format = %Ln

debug_log_path = /var/log/dovecot.log

info_log_path = /var/log/dovecot.log

listen = *

log_path = /var/log/dovecot.log

mail_gid = postfix

mail_location = maildir:~/Maildir

mail_privileged_group = postfix

mail_uid = postfix

managesieve_notify_capability = mailto

managesieve_sieve_capability = fileinto reject envelope encoded-character
vacati
on subaddress comparator-i;ascii-numeric relational regex imap4flags copy
includ
e variables body enotify environment mailbox date index ihave duplicate mime
for
everypart extracttext imapsieve

namespace inbox {

  inbox = yes

  location =

  mailbox "Deleted Items" {

special_use = \Trash

  }

  mailbox Drafts {

auto = subscribe

special_use = \Drafts

  }

  mailbox Junk {

auto = subscribe

special_use = \Junk

  }

  mailbox Sent {

auto = subscribe

special_use = \Sent

  }

  mailbox Spam {

auto = subscribe

special_use = \Junk

  }

  mailbox Trash {

auto = subscribe

special_use = \Trash

  }

  prefix =

  separator = .

}

passdb {

  driver = pam

}

passdb {

  driver = pam

}

plugin {

  imapsieve_mailbox1_before = file:/var/vmail/sieve/global/learn-spam.sieve

  imapsieve_mailbox1_causes = COPY

  imapsieve_mailbox1_name = Spam

  imapsieve_mailbox2_before = file:/var/vmail/sieve/global/learn-ham.sieve

  imapsieve_mailbox2_causes = COPY

  imapsieve_mailbox2_from = Spam

  imapsieve_mailbox2_name = *

  quota = maildir:User quota

  quota_exceeded_message = Benutzer %u hat das Speichervolumen
überschritten. /
User %u has exhausted allowed storage space.

  sieve = ~/.dovecot.sieve

  sieve_before = /var/vmail/sieve/global/spam-global.sieve

  sieve_extensions = +vnd.dovecot.pipe +vnd.dovecot.filter

  sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.filter

  sieve_implicit_extensions = +vnd.dovecot.pipe +vnd.dovecot.filter

  sieve_pipe_bin_dir = /var/vmail/sieve/global

  sieve_plugins = sieve_imapsieve sieve_extprograms

  sieve_trace_level = tests

  sieve_user_log = ~/.dovecot.sieve.log

}

postmaster_address = postmas...@hertes.net

protocols = imap lmtp sieve

service auth {

  unix_listener /var/spool/postfix/private/auth {

group = postfix

mode = 0660

user = postfix

  }

  unix_listener auth-userdb {

group = postfix

mode = 0660

user = postfix

  }

}

service imap-login {

  inet_listener imaps {

address = *

  }

  process_min_avail = 1

}

service lmtp {

  unix_listener /var/spool/postfix/private/dovecot-lmtp {

group = postfix

mode = 0600

user = postfix

  }

}

service managesieve-login {

  inet_listener sieve {

port = 4190

  }

}

service managesieve {

  process_limit = 1024

}

service pop3-login {

  inet_listener pop3s {

address = *

  }

}

ssl = required

ssl_cert = 

Re: 2.3.2.1 - EC keys suppport?

[Aki Tuomi]

> On 29 July 2018 at 23:39 ѽ҉ᶬḳ℠  wrote:
> 
> 
> 
> >> facing [ no shared cipher ] error with EC private keys.
> > the client connecting to your instance has to support ecdsa
> >
> >
> 
> It does - Thunderbird 60.0b10 (64-bit)
> 
> [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
> 
> It seems there is a difference between the private key (rsa vs. ecc ->
> SSL_CTX?) used for the certificate signing request and the signed
> certificate.
> 
> The csr created from a private key with [ openssl genpkey -algorithm RSA
> ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
> 
> But as stated in the initial message it does not work if the private key
> for the csr is generated with [ openssl ecparam -name brainpoolP512t1
> -genkey ].
> 
>

Can you try, with your ECC cert,

openssl s_client -connect server:143 -starttls imap

and paste result?

Aki

Re: dovecot 2.3.x, ECC and wildcard certificates, any issues

[Aki Tuomi]

> On 30 July 2018 at 19:16 David Mehler  wrote:
> 
> 
> Hello,
> 
> Does dovecot 2.3.x have any issues recognizing or using certificates
> that are ECC and wildcard? I'm trying to switch my letsencrypt
> implementation from acme-client which does not support either of those
> capabilities to acme.sh which does. Since then external clients
> checking their email has not worked. A manual telnet to
> mail.example.com 993 gives a connected message but then nothing no
> greeting or capabilities.
> 
> The certificate is for example.com with an alt name of *.example.com
> if that's not right let me know, i'm not sure about that one,
> connecting to the web sites of these pages seems noticeably slower,
> I'm wondering if both of these issues aren't key related?
> 
> Thanks.
> Dave.

These both should be fine.

Port 993 is TLS encrypted, you should use openssl s_client -connect server:993

Aki

dovecot 2.3.x, ECC and wildcard certificates, any issues

[David Mehler]

Hello,

Does dovecot 2.3.x have any issues recognizing or using certificates
that are ECC and wildcard? I'm trying to switch my letsencrypt
implementation from acme-client which does not support either of those
capabilities to acme.sh which does. Since then external clients
checking their email has not worked. A manual telnet to
mail.example.com 993 gives a connected message but then nothing no
greeting or capabilities.

The certificate is for example.com with an alt name of *.example.com
if that's not right let me know, i'm not sure about that one,
connecting to the web sites of these pages seems noticeably slower,
I'm wondering if both of these issues aren't key related?

Thanks.
Dave.

Re: question about using procmail

[Michael Wagner]

On Jul 30, 2018 um 16:48:13, Joe Wong wrote:
> Hello, I am new to Dovecot, testing the setup with Solr FTS plugin. Currently 
> I
> am using procmail to delivery email into user's mailbox. I am using maildir on
> file system. I found that if email is delivered via procmail, the
> indexer-worker is not being called. But when I move the email between folders
> via IMAP, indexer is involved. Is this expected?

Hello Joe,

I ran in the problem a few weeks ago. You must use dovecot for delivery 
in your procmailrc. I have

--

DELIVER=/usr/lib/dovecot/deliver

:0
* ^Subject:.*apt-listchanges
| $DELIVER -m apt-listchanges

--

-m mailbox
Destination  mailbox  (default  is INBOX).  If the mailbox doesn't 
exist, it will not be created (unless the lda_mailbox_autocreate setting 
is set to yes).  If a message couldn't be saved to the mailbox for any 
reason, it's delivered to INBOX instead.

Hth Michael

-- 
Never test for an error you don't know how to handle.


signature.asc
Description: PGP signature

Re: question about using procmail

[Aki Tuomi]

dovecot will only do indexing on delivery if you deliver using dovecot. 


---Aki TuomiDovecot oy
 Original message From: Joe Wong  Date: 
30/07/2018  11:48  (GMT+02:00) To: dovecot@dovecot.org Subject: question about 
using procmail 
Hello, I am new to Dovecot, testing the setup with Solr FTS plugin. Currently I 
am using procmail to delivery email into user's mailbox. I am using maildir on 
file system. I found that if email is delivered via procmail, the 
indexer-worker is not being called. But when I move the email between folders 
via IMAP, indexer is involved. Is this expected?
- Joe

question about using procmail

[Joe Wong]

Hello, I am new to Dovecot, testing the setup with Solr FTS plugin.
Currently I am using procmail to delivery email into user's mailbox. I am
using maildir on file system. I found that if email is delivered via
procmail, the indexer-worker is not being called. But when I move the email
between folders via IMAP, indexer is involved. Is this expected?

- Joe

Re: 2.3.2.1 - EC keys suppport?

[ѽ҉ᶬḳ℠]

 facing [ no shared cipher ] error with EC private keys.
>>> the client connecting to your instance has to support ecdsa
>>>
>>>
>> It does - Thunderbird 60.0b10 (64-bit)
>>
>> [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ]
>>
>> It seems there is a difference between the private key (rsa vs. ecc ->
>> SSL_CTX?) used for the certificate signing request and the signed
>> certificate.
>>
>> The csr created from a private key with [ openssl genpkey -algorithm RSA
>> ] and signed by a CA with [ ecdhe_ecdsa ] works with no error.
>>
>> But as stated in the initial message it does not work if the private key
>> for the csr is generated with [ openssl ecparam -name brainpoolP512t1
>> -genkey ].
>>
>>
>
> Can you show doveconf ssl_cipher_list?
>

Tried several variations, e.g. ALL, ALL:HIGH:MEDIUM:LOW and right now
set to
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384
which is working fine when the csr was created from a private key with
RSA algorithm but not if csr key is generated with an EC key.