Re: Problem with Let's Encrypt Certificate

[chaouche yacine]

Interesting. Is there any particular benefit in having only one file for both 
certificate and private key ? I find that putting private key in a separate 
file feels more secure.


Bastian, how could two identical certificates be processed differently by 
Thunderbid ? how did you check the differences between the two ? did you use 
"diff" ? did you compare the output of openssl x509 commands ? what method did 
you choose ?


-- Yassine.

Re: Sieve not filtering

[Doug Hardie]

> On 17 February 2017, at 08:24, Ben  wrote:
> 
> Hi,
> 
> I have copied accross a known-good sieve file from a working server and its 
> not filtering.  Everything just gets chucked into INBOX.

What I did when encountering a similar issue was to take one of the messages 
from INBOX that should have been moved elsewhere and use sieve-test on it:

sieve-test -Tlevel=matching  

That generates a lot of output as it goes through every line of the sieve file 
and shows the actual values that are used for the tests.  However, it pointed 
out my problem quite clearly.

Re: Problem with Let's Encrypt Certificate

[Shawn Heisey]

On 2/17/2017 2:38 PM, chaouche yacine wrote:
> Seems wrong to me too, Robert. If you put your private key inside your 
> certificate, won't it be sent to the client along with it ?

The private key should not be sent to the connecting client, even if it
is contained in the same place as the certificate(s).  If that data *is*
sent to the client, that's a bug, probably in the SSL library (usually
openssl).

I am not using letsencrypt for my personal install, but my certificate
provider does use one intermediate, just like letsencrypt does.  I have
the server certificate, the intermediate certificate, and the private
key all in the same file, and my dovecot config contains these lines,
both referring to that file:

ssl_cert_file = /etc/ssl/certs/local/imap.REDACTED.com.pem
ssl_key_file = /etc/ssl/certs/local/imap.REDACTED.com.pem

This file is owned by root and has 600 permissions.  Because root
permissions are required in order to bind to port numbers below 1024,
dovecot typically will initially start as root, then drop permissions as
required.

hostname:/etc/ssl/certs/local# ls -al imap.REDACTED.com.pem
-rw--- 1 root root 6266 Jan  6 20:47 imap.REDACTED.com.pem

Thanks,
Shawn

Re: Problem with Let's Encrypt Certificate

[Bastian Sebode]

Hey.

Thanks again for your help. I took the "dovecot -n" while the StartSSL
Certificate was active, so the chain.pem was correct.

Finally I found the issue! :-) But I still have no idea why the problem
happens with Thunderbird.

I used dehydrated to fetch the certificates from Let's Encrypt and as I
said, it works for most clients pretty well. (Tried: Mulberry, Claws
Mail, Outlook 2010, Android (HTC), iPhone, ...) Also it works perfectly
with all my HTTPS-Services

Whatever, Thunderbird didn't like that cert saying "bad certificate"
(SSL Alert 42).

Now I fetched the cert with Certbot and it works. Really strange though!

I checked for any obvious differences between the certificates and
private keys, but couldn't find any.

So my solution will be to use certbot instead of dehydrated... :-/

Worst thing is, that a Microsoft Blog article
(https://blogs.msdn.microsoft.com/kaushal/2012/10/05/ssltls-alert-protocol-the-alert-codes/)
led me to the right direction ;-)
--
42  bad_certificate "There is a problem with the certificate, for
example, a certificate is corrupt, or a certificate contains signatures
that cannot be verified."
--

Peace
Bastian

Am 17.02.2017 um 21:58 schrieb Aki Tuomi:
> Usually with LE, the filename is fullchain.pem, not chain.pem.
> 
> Can you please doublecheck this?
> 
> Also, try
> 
> openssl s_client -connect hostname:143 -starttls imap
> 
> Aki
> 
>> On February 17, 2017 at 10:31 PM Bastian Sebode  
>> wrote:
>>
>>
>> Hey Robert,
>>
>> thanks for your reply.
>>
>> Am 17.02.2017 um 19:28 schrieb Robert L Mathews:
>>> Looking at your dovecot -n, you're using two different files here:
>>>
>>> ssl_cert = >> ssl_key = >>
>>> Are you sure these two files match, and contain the right things in the
>>> right order?
>>>
>> Yes, unfortunately I'm sure that everything has the right order. As you
>> can see in the trace, both certificates (mine and the intermediate) get
>> transferred to the client on connection.
>>
>>> We use a single PEM file as input for both of these parameters, and that
>>> PEM file contains, in this order:
>>>
>>> -BEGIN RSA PRIVATE KEY-
>>> ...
>>> -BEGIN CERTIFICATE-
>>> ...
>>> -BEGIN CERTIFICATE-
>>>
>>> ... where the first BEGIN CERTIFICATE is the specific hostname one, and
>>> the second BEGIN CERTIFICATE is the Let's Encrypt X3 intermediate
>>> certificate that ends with "DNFu0Qg==".
>>>
>> Tried that, but without success. But your usage doesn't seem right to
>> me. The parameters are not called ssl_cert and ssl_key for nothing. ;-)
>> Normally you don't want your private key to have any other permissions
>> than 600.
>>
>>> You're also manually specifying these non-default parameters:
>>>
>>> ssl_cipher_list = ...
>>> ssl_prefer_server_ciphers = yes
>>> ssl_protocols = !SSLv2 !SSLv3
>>>
>>> For testing, I would simplify. Does it work without any of those three
>>> things set?
>>>
>> Tried this before. I set all SSL specific settings exactly like my
>> friend where it works without a problem. But it doesn't work for me.
>>
>> Thanks anyway for your effort!
>> Bastian
>> -- 
>> Bastian Sebode
>> Fachinformatiker Systemintegration
>>
>> LINET Services GmbH | Cyriaksring 10a | 38118 Braunschweig
>> Tel. 0531-180508-0 | Fax 0531-180508-29 | http://www.linet-services.de
>>
>> LINET in den sozialen Netzwerken:
>> www.twitter.com/linetservices | www.facebook.com/linetservices
>> Wissenswertes aus der IT-Welt: www.linet-services.de/blog/
>>
>> Geschäftsführung: Timo Springmann, Mirko Savic und Moritz Bunkus
>> HR B 9170 Amtsgericht Braunschweig
>>
>> USt-IdNr. DE 259 526 516

-- 
Bastian Sebode
Fachinformatiker Systemintegration

LINET Services GmbH | Cyriaksring 10a | 38118 Braunschweig
Tel. 0531-180508-0 | Fax 0531-180508-29 | http://www.linet-services.de

LINET in den sozialen Netzwerken:
www.twitter.com/linetservices | www.facebook.com/linetservices
Wissenswertes aus der IT-Welt: www.linet-services.de/blog/

Geschäftsführung: Timo Springmann, Mirko Savic und Moritz Bunkus
HR B 9170 Amtsgericht Braunschweig

USt-IdNr. DE 259 526 516

Re: Problem with Let's Encrypt Certificate

[Christian Kivalo]

On 2017-02-17 22:38, chaouche yacine wrote:

Seems wrong to me too, Robert. If you put your private key inside your
certificate, won't it be sent to the client along with it ?
This is one way of supplying cert + key to a daemon and no, the key is 
not sent to the client.


While it is normaly true that one doesn't want the key to have access 
rights other than 0600, with dovecot as the file owner of the 
key+cert+intermediate .pem file the access rights can be set to 0600.


--
 Christian Kivalo

Re: Problem with Let's Encrypt Certificate

[chaouche yacine]

Seems wrong to me too, Robert. If you put your private key inside your 
certificate, won't it be sent to the client along with it ?

Bastian, are you using an old version of thunderbird ? googling for "SSL alert 
number 42" gave me two results indicating a bug in thunderbird versions 31,32 
and 33. You can check these links if you wish : 


* http://www.dovecot.org/list/dovecot/2014-July/097133.html
* 
http://unix.stackexchange.com/questions/123367/thunderbird-fails-to-connect-to-dovecot-and-postfix


-- Yassine




On Friday, February 17, 2017 7:29 PM, Robert L Mathews  
wrote:



On 2/17/17 8:58 AM, Bastian Sebode wrote:


> I uploaded two Wireshark tracefiles, further logs and dovecot -n

Looking at your dovecot -n, you're using two different files here:

ssl_cert = http://www.tigertech.net/

Re: Problem with Let's Encrypt Certificate

[Aki Tuomi]

Usually with LE, the filename is fullchain.pem, not chain.pem.

Can you please doublecheck this?

Also, try

openssl s_client -connect hostname:143 -starttls imap

Aki

> On February 17, 2017 at 10:31 PM Bastian Sebode  
> wrote:
> 
> 
> Hey Robert,
> 
> thanks for your reply.
> 
> Am 17.02.2017 um 19:28 schrieb Robert L Mathews:
> > Looking at your dovecot -n, you're using two different files here:
> > 
> > ssl_cert =  > ssl_key =  > 
> > Are you sure these two files match, and contain the right things in the
> > right order?
> > 
> Yes, unfortunately I'm sure that everything has the right order. As you
> can see in the trace, both certificates (mine and the intermediate) get
> transferred to the client on connection.
> 
> > We use a single PEM file as input for both of these parameters, and that
> > PEM file contains, in this order:
> > 
> > -BEGIN RSA PRIVATE KEY-
> > ...
> > -BEGIN CERTIFICATE-
> > ...
> > -BEGIN CERTIFICATE-
> > 
> > ... where the first BEGIN CERTIFICATE is the specific hostname one, and
> > the second BEGIN CERTIFICATE is the Let's Encrypt X3 intermediate
> > certificate that ends with "DNFu0Qg==".
> >
> Tried that, but without success. But your usage doesn't seem right to
> me. The parameters are not called ssl_cert and ssl_key for nothing. ;-)
> Normally you don't want your private key to have any other permissions
> than 600.
> 
> > You're also manually specifying these non-default parameters:
> > 
> > ssl_cipher_list = ...
> > ssl_prefer_server_ciphers = yes
> > ssl_protocols = !SSLv2 !SSLv3
> > 
> > For testing, I would simplify. Does it work without any of those three
> > things set?
> > 
> Tried this before. I set all SSL specific settings exactly like my
> friend where it works without a problem. But it doesn't work for me.
> 
> Thanks anyway for your effort!
> Bastian
> -- 
> Bastian Sebode
> Fachinformatiker Systemintegration
> 
> LINET Services GmbH | Cyriaksring 10a | 38118 Braunschweig
> Tel. 0531-180508-0 | Fax 0531-180508-29 | http://www.linet-services.de
> 
> LINET in den sozialen Netzwerken:
> www.twitter.com/linetservices | www.facebook.com/linetservices
> Wissenswertes aus der IT-Welt: www.linet-services.de/blog/
> 
> Geschäftsführung: Timo Springmann, Mirko Savic und Moritz Bunkus
> HR B 9170 Amtsgericht Braunschweig
> 
> USt-IdNr. DE 259 526 516

Re: Problem with Let's Encrypt Certificate

[KSB]

On 2017.02.17. 22:31, Bastian Sebode wrote:

Hey Robert,

thanks for your reply.

Am 17.02.2017 um 19:28 schrieb Robert L Mathews:

Looking at your dovecot -n, you're using two different files here:

ssl_cert = 

Are You sure, chain.pem contains your cert + immediate? By default 
certbot in chain.pem includes only itermediate cert's and if you wan't 
everything, it's included in fullchain.


--
KSB

Re: Problem with Let's Encrypt Certificate

[Bastian Sebode]

Hey Robert,

thanks for your reply.

Am 17.02.2017 um 19:28 schrieb Robert L Mathews:
> Looking at your dovecot -n, you're using two different files here:
> 
> ssl_cert =  ssl_key =  
> Are you sure these two files match, and contain the right things in the
> right order?
> 
Yes, unfortunately I'm sure that everything has the right order. As you
can see in the trace, both certificates (mine and the intermediate) get
transferred to the client on connection.

> We use a single PEM file as input for both of these parameters, and that
> PEM file contains, in this order:
> 
> -BEGIN RSA PRIVATE KEY-
> ...
> -BEGIN CERTIFICATE-
> ...
> -BEGIN CERTIFICATE-
> 
> ... where the first BEGIN CERTIFICATE is the specific hostname one, and
> the second BEGIN CERTIFICATE is the Let's Encrypt X3 intermediate
> certificate that ends with "DNFu0Qg==".
>
Tried that, but without success. But your usage doesn't seem right to
me. The parameters are not called ssl_cert and ssl_key for nothing. ;-)
Normally you don't want your private key to have any other permissions
than 600.

> You're also manually specifying these non-default parameters:
> 
> ssl_cipher_list = ...
> ssl_prefer_server_ciphers = yes
> ssl_protocols = !SSLv2 !SSLv3
> 
> For testing, I would simplify. Does it work without any of those three
> things set?
> 
Tried this before. I set all SSL specific settings exactly like my
friend where it works without a problem. But it doesn't work for me.

Thanks anyway for your effort!
Bastian
-- 
Bastian Sebode
Fachinformatiker Systemintegration

LINET Services GmbH | Cyriaksring 10a | 38118 Braunschweig
Tel. 0531-180508-0 | Fax 0531-180508-29 | http://www.linet-services.de

LINET in den sozialen Netzwerken:
www.twitter.com/linetservices | www.facebook.com/linetservices
Wissenswertes aus der IT-Welt: www.linet-services.de/blog/

Geschäftsführung: Timo Springmann, Mirko Savic und Moritz Bunkus
HR B 9170 Amtsgericht Braunschweig

USt-IdNr. DE 259 526 516

Replication Troubles

[Wolfgang Hennerbichler]

Hi Dovecot Users, 

I’ve configured dovecot dsync replication and I see troubles in the logs and 
get user complaints which I can’t explain. I found similar threads on this 
mailinglist, but I couldn’t find a solution anywhere. Does anybody have dsync 
running without problems on a high volume mailserver?

I see the following logs, examples given: 

Feb 17 18:16:49 dovecot dovecot: imap(zoechi): Warning: 
/var/mail/zoechi/dovecot-uidlist: Duplicate file entry at line 10395: 
1487350019.M138380P28563.dovecot.wogri.at,S=18930,W=19377 (uid 41092 -> 41093) 
- retrying by re-reading from beginning

with this one I’m not sure - it might be that this is completely OK because due 
to replication UIDs clash. Maybe that’s OK, but I couldn’t find a confirmation. 

Feb 17 18:16:49 dovecot dovecot: imap(zoechi): Warning: Maildir 
/var/mail/zoechi: Expunged message reappeared, giving a new UID (old uid=41092, 
file=1487350019.M138380P28563.dovecot.wogri.at,S=18930,W=19377)

This one is definitely a problem, deleted messages re-appear in the mailbox. 

I made sure that the 2 hosts doing replication have different hostnames. I run 
2.2.27 (from debian-jessie backports). Config below. 

Thanks for hints (or pointers to other example configs where dsync works 
without problems) 


# dovecot -n 
# 2.2.27 (c0f36b0): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.16 (fed8554)
# OS: Linux 4.8.14 x86_64 Debian 8.7 ext4
auth_verbose = yes
debug_log_path = /var/log/dovecot.debug
doveadm_password =  # hidden, use -P to show it
first_valid_gid = 106
first_valid_uid = 104
hostname = localhost
last_valid_gid = 106
last_valid_uid = 104
mail_gid = dovecot
mail_location = maildir:/var/mail/%n
mail_plugins = quota fts fts_lucene virtual notify replication
mail_temp_dir = /var/lib/dovecot/tmp
mail_uid = dovecot
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 editheader
namespace {
  list = children
  location = virtual:/var/mail/%n/virtual
  prefix = virtual.
  separator = .
}
namespace inbox {
  inbox = yes
  list = yes
  location = 
  mailbox "Deleted Messages" {
auto = subscribe
special_use = \Trash
  }
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox "Sent Messages" {
auto = no
special_use = \Sent
  }
  mailbox Spam {
auto = subscribe
special_use = \Junk
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix = 
  separator = .
  subscriptions = yes
  type = private
}
passdb {
  args = /etc/dovecot/dovecot-ldap.conf.ext
  driver = ldap
}
plugin {
  default_language = de
  fts = lucene
  fts_lucene = whitespace_chars=@.
  mail_replica = tcp:172.16.1.1:12345
  quota = maildir:User quota
  quota_rule = *:storage=5G
  quota_rule2 = Trash:storage=+200M
  quota_rule3 = Spam:ignore
  quota_warning = storage=95%% quota-warning 95 %u
  quota_warning2 = storage=80%% quota-warning 80 %u
  sieve = /etc/sieve/%n.sieve
  sieve_default = /etc/sieve/default.sieve
  sieve_dir = ~/sieve
  sieve_extensions = +editheader
}
pop3_deleted_flag = $POP3Deleted
postmaster_address = postmas...@wogri.at
protocols = " imap lmtp sieve pop3"
service aggregator {
  fifo_listener replication-notify-fifo {
user = dovecot
  }
  unix_listener replication-notify {
user = dovecot
  }
}
service doveadm {
  inet_listener {
port = 12345
  }
}
service imap {
  process_limit = 1024
}
service lmtp {
  inet_listener lmtp {
port = 2003
  }
  unix_listener lmtp {
user = dovecot
  }
  user = dovecot
}
service managesieve-login {
  inet_listener sieve {
port = 4190
  }
  service_count = 1
}
service pop3 {
  process_limit = 1024
}
service quota-warning {
  executable = script /usr/local/sbin/quota-warning.sh
  unix_listener quota-warning {
user = dovecot
  }
  user = dovecot
}
service replicator {
  process_min_avail = 1
  unix_listener replicator-doveadm {
mode = 0600
  }
}
ssl = required
ssl_cert = 

Re: Problem with Let's Encrypt Certificate

[Robert L Mathews]

On 2/17/17 8:58 AM, Bastian Sebode wrote:

> I uploaded two Wireshark tracefiles, further logs and dovecot -n

Looking at your dovecot -n, you're using two different files here:

ssl_cert = http://www.tigertech.net/

Problem with Let's Encrypt Certificate

[Bastian Sebode]

Hello Folks,

my StartCom SSL-Certificate expires soon and so I wanted to switch to
Let's Encrypt Certificates instead. Unfortunatelly Thunderbird seems not
to like it, although all -tested- other Clients work without any problems.

When I connect with Thunderbird it sends an "Encrypted Alert" directly
after the TLS handshake although Dovecot wants to continue the session.

In the Dovecot Log it says:
Feb 17 17:27:17 imap-login: Debug: SSL: where=0x20, ret=1: SSL
negotiation finished successfully [82.100.242.26]
Feb 17 17:27:17 imap-login: Debug: SSL: where=0x2002, ret=1: SSL
negotiation finished successfully [82.100.242.26]
Feb 17 17:27:17 imap-login: Warning: SSL alert: where=0x4004, ret=554:
fatal bad certificate [82.100.242.26]

But the certificate is okay, cause it works with other Mailclients and
openssl also says so. What certificate is Thunderbird complaining about?

Thunderbird says something like "There's no supported authentication
method". I don't use any Certificates for Client Authentication, neither
in Dovecot nor in Thunderbird. When I do, it fails the same way.

Weirdly my friend uses the same Dovecot Version with Let's Encrypt on
his Server and it works with Thunderbird without any flaws. Mine fails
the same way in his Thunderbird and also in a fresh installation.

After two weeks of investigating I still have no clue why it behaves
like this.

I uploaded two Wireshark tracefiles, further logs and dovecot -n, may be
someone sees any possible reasons for this weird behavior or has any
further tips on solving this issue.
https://sebode-online.de/dovecot-letsencrypt/

Every hint is highly appreciated!

Best Regards
Bastian

-- 
Bastian Sebode
Fachinformatiker Systemintegration

LINET Services GmbH | Cyriaksring 10a | 38118 Braunschweig
Tel. 0531-180508-0 | Fax 0531-180508-29 | http://www.linet-services.de

LINET in den sozialen Netzwerken:
www.twitter.com/linetservices | www.facebook.com/linetservices
Wissenswertes aus der IT-Welt: www.linet-services.de/blog/

Geschäftsführung: Timo Springmann, Mirko Savic und Moritz Bunkus
HR B 9170 Amtsgericht Braunschweig

USt-IdNr. DE 259 526 516

Re: fts_solr and connection via https://

[Jan Vonde]

Am 17.02.2017 um 11:45 schrieb Stephan Bosch:

Op 8-2-2017 om 21:07 schreef Jan Vonde:

Am 07.02.2017 um 12:29 schrieb Stephan Bosch:

Op 31-1-2017 om 6:33 schreef Jan Vonde:

Am 31.01.2017 um 00:04 schrieb Stephan Bosch:

Op 1/22/2017 om 12:01 PM schreef Stephan Bosch:

Op 1/22/2017 om 10:01 AM schreef Jan Vonde:

I tried adding the following settings but that didn't help:
   ssl_ca = < /etc/ssl/certs/ca-certificates.crt
   ssl_client_ca_dir = /etc/ssl/certs

Can you give me a hint how I can get the ssl certificate accepted?

That should normally have done the trick. However, the sources
tell me
that no ssl_client settings are propagated to the http_client used by
fts-solr, so SSL is not currently supported it seems.

I'll check how easy it is to add that.

Just to keep you informed: I created a patch, but it is still being
tested.


Thanks for the update Stephan! Awesome! Looking forward to test it
myself :-)

https://github.com/dovecot/core/commit/526631052ca3175357302af8fa7dcbf763b40c53



Thank you. I am using now the following version:
   2.3.0.alpha0 (2eeea57) [XI:2:2.3.0~alpha0-1~auto+650]

The error messages I am getting now are like this:

doveadm(user@host): Info: Received invalid SSL certificate: unable to
get local issuer certificate: /C=US/O=Let's Encrypt/CN=Let's Encrypt
Authority X3
doveadm(user@host): Error: fts_solr: Lookup failed: 9002 SSL handshaking
with 5.45.106.248:443 failed: read(SSL 5.45.106.248:443) failed:
Received invalid SSL certificate: unable to get local issuer
certificate: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3


You can connect to 5.45.106.248:443 and IMHO everything is correct with
the chain.


I am no SSL expert, but I am reading it as "doveadm and its ssl part
cannot verify the Let's Encrypt certificate". It would need the DST Root
CA X3 and this is in the local trust store (ssl_client_ca_dir...)


Do you have another hint maybe?


We seem to have found another issue there. More on this will follow.


Thanks for the update and have a nice weekend,


Jan :-)

Sieve not filtering

[Ben]

Hi,

I have copied accross a known-good sieve file from a working server and 
its not filtering.  Everything just gets chucked into INBOX.


doveconf-n at the bottom of this mail

Feb 17 16:05:20 server postfix/smtpd[51562]: 7FA5E12CBBC: 
client=unknown[192.168.167.57]

Feb 17 16:05:23 server postfix/cleanup[51565]: 7FA5E12CBBC: message-id=<>
Feb 17 16:05:23 server postfix/qmgr[45471]: 7FA5E12CBBC: 
from=, size=182, nrcpt=1 (queue active)

Feb 17 16:05:23 server dovecot: lmtp(51467): Connect from local
Feb 17 16:05:23 server dovecot: auth-worker(51568): 
passwd(recipi...@example.com): unknown user
Feb 17 16:05:23 server dovecot: lmtp(51467, recipi...@example.com): 
1JK2B0Mfp1gLyQAAHLpRfg: sieve: msgid=unspecified: stored mail into 
mailbox 'INBOX'
Feb 17 16:05:23 server dovecot: lmtp(51467): Disconnect from local: 
Successful quit
Feb 17 16:05:23 server postfix/lmtp[51566]: 7FA5E12CBBC: 
to=, 
orig_to=, 
relay=server.example.com[private/dovecot-lmtp], delay=4.9, 
delays=4.9/0.01/0/0.05, dsn=2.0.0, status=sent (250 2.0.0 
 1JK2B0Mfp1gLyQAAHLpRfg Saved)

Feb 17 16:05:23 server postfix/qmgr[45471]: 7FA5E12CBBC: removed


This is the syntax I'm using in my sieve file:
require ["fileinto","envelope"];
if anyof (address :is :all "to" 
["recipient+someth...@example.com”,”mailing_l...@example.com”],
   header :contains ["Cc", "Delivered-To"] 
["recipient+someth...@example.com”,”mailing_l...@example.com”]) {

fileinto “THIS_FOLDER”;
stop;
}



# 2.2.10: /etc/dovecot/dovecot.conf
# OS: Linux 3.10.0-514.6.1.el7.x86_64 x86_64 CentOS Linux release 
7.3.1611 (Core)

auth_mechanisms = plain login
auth_verbose = yes
auth_verbose_passwords = sha1
first_valid_uid = 1000
mail_location = maildir:~/Maildir
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 environment 
mailbox date ihave enotify

mbox_write_locks = fcntl
namespace inbox {
  inbox = yes
  location =
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix =
}
passdb {
  driver = pam
}
passdb {
  driver = pam
}
passdb {
  args = scheme=CRYPT username_format=%u /etc/dovecot/users
  driver = passwd-file
}
plugin {
  sieve = ~/.dovecot.sieve
}
protocols = imap lmtp
service auth {
  unix_listener /var/spool/postfix/private/dovecot-auth {
group = postfix
mode = 0660
user = postfix
  }
  unix_listener auth-userdb {
group = its_virtmail
mode = 0660
user = its_virtmail
  }
}
service imap-login {
  process_min_avail = 3
}
service lmtp {
  process_min_avail = 5
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0600
user = postfix
  }
  user = its_virtmail
}
service managesieve-login {
  inet_listener sieve {
port = 4190
  }
  inet_listener sieves {
address =
port = 5190
ssl = yes
  }
}
ssl = required
ssl_cert =  was automatically rejected:%n%r
}
protocol imap {
  imap_client_workarounds = delay-newmail
  mail_max_userip_connections = 20
}

Re: Sieve removeflag Action

[Stephan Bosch]

Op 19-1-2017 om 10:43 schreef Thomas Leuxner:

* Stephan Bosch  2017.01.19 10:32:


Could you provide a more detailed example?

Sure. Personal script v

/var/vmail/domains/leuxner.net/tlx/.dovecot.sieve:

require ["include","copy","fileinto","imap4flags","vacation"];
include :global "global";

--

Global script referenced v

/var/vmail/conf.d/leuxner.net/sieve/global.sieve:

require ["fileinto","imap4flags","duplicate"];

#Newsletters

if header :contains "List-Id" "debian-security-announce.lists.debian.org"
 {
 removeflag "\\Flagged $MailFlagBit1";
 fileinto ":public/Newsletters/Debian/Security";
 addflag "\\Flagged $MailFlagBit1";
 keep;
 }

--
Basically it is reproducible with the same stanza we used before by putting 
this in the included script:

#Test
if address :is "From" "u...@example.com"
{
removeflag "\\Flagged $MailFlagBit1";
fileinto "Trash";
addflag "\\Flagged $MailFlagBit1";
keep;
}


Couldn't reproduce this with v2.3.devel yesterday (i.e. no flags set for 
the Security mailbox and all flags set for the message in INBOX), but I 
will try later with some older version.


Regards,

Stephan.

Re: fts_solr and connection via https://

[Stephan Bosch]

Op 8-2-2017 om 21:07 schreef Jan Vonde:

Am 07.02.2017 um 12:29 schrieb Stephan Bosch:


Op 31-1-2017 om 6:33 schreef Jan Vonde:

Am 31.01.2017 um 00:04 schrieb Stephan Bosch:

Op 1/22/2017 om 12:01 PM schreef Stephan Bosch:

Op 1/22/2017 om 10:01 AM schreef Jan Vonde:

I tried adding the following settings but that didn't help:
   ssl_ca = < /etc/ssl/certs/ca-certificates.crt
   ssl_client_ca_dir = /etc/ssl/certs

Can you give me a hint how I can get the ssl certificate accepted?

That should normally have done the trick. However, the sources tell me
that no ssl_client settings are propagated to the http_client used by
fts-solr, so SSL is not currently supported it seems.

I'll check how easy it is to add that.

Just to keep you informed: I created a patch, but it is still being
tested.


Thanks for the update Stephan! Awesome! Looking forward to test it
myself :-)

https://github.com/dovecot/core/commit/526631052ca3175357302af8fa7dcbf763b40c53


Thank you. I am using now the following version:
   2.3.0.alpha0 (2eeea57) [XI:2:2.3.0~alpha0-1~auto+650]

The error messages I am getting now are like this:

doveadm(user@host): Info: Received invalid SSL certificate: unable to
get local issuer certificate: /C=US/O=Let's Encrypt/CN=Let's Encrypt
Authority X3
doveadm(user@host): Error: fts_solr: Lookup failed: 9002 SSL handshaking
with 5.45.106.248:443 failed: read(SSL 5.45.106.248:443) failed:
Received invalid SSL certificate: unable to get local issuer
certificate: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3


You can connect to 5.45.106.248:443 and IMHO everything is correct with
the chain.


I am no SSL expert, but I am reading it as "doveadm and its ssl part
cannot verify the Let's Encrypt certificate". It would need the DST Root
CA X3 and this is in the local trust store (ssl_client_ca_dir...)


Do you have another hint maybe?


We seem to have found another issue there. More on this will follow.

Regards,

Stephan.