Re: regarding ssl certificates
Is there some reason to use a mail.domain.com cert for mail rarher than just using domain.com for everything? Historically the subdomain were used because they were on different hardware. That is www was on one machine and mail was on another. Original Message From: dovecot@dovecot.org Sent: March 14, 2019 3:56 PM To: dovecot@dovecot.org Reply-to: jtam.h...@gmail.com Subject: Re: regarding ssl certificates mick crane wrote: > Apache2 default install has this snake oil certificate > Can make a new one for apache I won't go over some of the excellent points in previous posts, but I will mention SAN as a third type of certificate you can make. LetsEncrypt supports this type of certificate. This is halfway between single CN and wildcard certificate where you can combine many hostnames (up to 1000?) into one certificate. This may be useful if you want the convenience of handling fewer certificates, without having an unbounded wildcard certificate (the latter also requires control over your DNS). I use this for SMTPAUTH, POP3, IMAP and webmail services since they are all on one server. Then Stephan von Krawczynski wrote: > Sorry I have to write this, but this is again pointing people in a fake > security direction. > The only valid authority for a certificate is the party using it. Any third > party with unknown participants cannot be a "Certificate Authority" in its > true sense. This is why you should see "Let's Encrypt" simply as a cheap way > to fake security. It is a US entity, which means it _must_ hand out all > necessary keys to fake certificates to the US authorities _by law_. > Now probably you can imagine why they are giving the certificates out for > free. US authorities can compromise all of them - without any "open > knowledge". Wow, you packed a lot of fear, uncertainty and doubt (and some misinformation) into one paragraph. I'll leave it at that. Joseph Tam
Re: regarding ssl certificates
On Thu, 2019-03-14 at 15:08 +0100, Stephan von Krawczynski via dovecot wrote: > On Thu, 14 Mar 2019 09:51:14 -0400 > Phil Turmel via dovecot wrote: > > > On 3/14/19 7:40 AM, Stephan von Krawczynski via dovecot wrote: > > > > > Sorry I have to write this, but this is again pointing people in a fake > > > security direction. > > > > You should be sorry, because you are wrong. > > > > > The only valid authority for a certificate is the party using it. Any > > > third > > > party with unknown participants cannot be a "Certificate Authority" in its > > > true sense. This is why you should see "Let's Encrypt" simply as a cheap > > > way to fake security. It is a US entity, which means it _must_ hand out > > > all > > > necessary keys to fake certificates to the US authorities _by law_. > > > > Certificate authorities, including Let's Encrypt, operate on Certificate > > Signing Requests, not Private Keys. Some CAs do offer private key > > generation in their services for the user's convenience, but it is not > > recommended (obviously) and in no way required. Getting a CA to sign a > > CSR in no way exposes keys to that CA, and therefore not to any government. > > > > While there are weakness in the CA trust system, they aren't anything > > related to replacing a snakeoil cert with one from Let's Encrypt. > > > > [rest of ignorant rant trimmed] > > Some facts for you, as obviously you have not understood what a CA is worth > that is compromised by either hackers or "authorities". > If you want to know more, read articles about closing of CA DigiNotar, like: > https://en.wikipedia.org/wiki/DigiNotar > > Then read US export laws concerning security devices. > Then judge your US-issued certs... > > > Phil > I concur Stephan; I apologize to others if I seem ignorant. Just an FYI, a founder of Let's Encrypt, and host of it's website is Akamai, which also hosts nsa.gov, cia.gov, etc. Akami principal founders were a US guy and a US/Israeli spy guy. I once did a traceroute on the mailserver that sent me an email (from a bank); the route went over to Europe, to Virginia, back to Europe, then back to me (in the US). It made me laugh it was so obvious. The bank's service provider that provided the email service ? Akamai. Any time you're using the "internet", well, let's just say that many very intelligent people are quite naive when it comes to internet security. Encryption is just really not that much of a barrier any more. Developers are always told "don't roll your own encryption". Well, to even set up encryption software (algo selection, etc.), it's something that is beyond most of us. I always try to do at least some minimal research to see "what's what", and with encryption it always boils down to having very low confidence that what I'm setting up would take more than a few minutes for a serious "invader" to totally break through. Encryption is being used to promote a false sense of security. It could only be more obvious if NSA directly sold certificates themselves. I'm sure there would be many very intelligent folks who would happily purchase them and think they were the greatest thing since sliced bread. To close rant, in my humble opinion sure, encrypt if you like, give it your best effort, but don't assume that anything is "secure".
Re: regarding ssl certificates
mick crane wrote: Apache2 default install has this snake oil certificate Can make a new one for apache I won't go over some of the excellent points in previous posts, but I will mention SAN as a third type of certificate you can make. LetsEncrypt supports this type of certificate. This is halfway between single CN and wildcard certificate where you can combine many hostnames (up to 1000?) into one certificate. This may be useful if you want the convenience of handling fewer certificates, without having an unbounded wildcard certificate (the latter also requires control over your DNS). I use this for SMTPAUTH, POP3, IMAP and webmail services since they are all on one server. Then Stephan von Krawczynski wrote: Sorry I have to write this, but this is again pointing people in a fake security direction. The only valid authority for a certificate is the party using it. Any third party with unknown participants cannot be a "Certificate Authority" in its true sense. This is why you should see "Let's Encrypt" simply as a cheap way to fake security. It is a US entity, which means it _must_ hand out all necessary keys to fake certificates to the US authorities _by law_. Now probably you can imagine why they are giving the certificates out for free. US authorities can compromise all of them - without any "open knowledge". Wow, you packed a lot of fear, uncertainty and doubt (and some misinformation) into one paragraph. I'll leave it at that. Joseph Tam
Dovecot crashing when attempting to search in virtual folder with fts_squat activated
Hi everyone,
I am running into a problem when trying to use fts_squat in a virtual
folder. Without fts_squat plugin the search (from, subject...) works in
all folders. With activated fts the search on the inbox folders works
expectedly well but any attempt to search anything in any virtual folder
leads to the following error. Similarly when attempting "doveadm fts
lookup". I also noticed that no search index for the virtual folders
gets build - is this expected behaviour?
Mar 14 23:14:58 *** dovecot: service=imap, user=***, ip=[::1].
Panic: file mail-storage.c: line 1913 (mailbox_get_open_status):
assertion failed: (box->opened)
Mar 14 23:14:58 *** dovecot: service=imap, user=***, ip=[::1].
Error: Raw backtrace:
/usr/lib/x86_64-linux-gnu/dovecot/libdovecot.so.0(+0xba731)
[0x7f553a7ff731] ->
/usr/lib/x86_64-linux-gnu/dovecot/libdovecot.so.0(+0xba7fa)
[0x7f553a7ff7fa] ->
/usr/lib/x86_64-linux-gnu/dovecot/libdovecot.so.0(i_fatal+0)
[0x7f553a771638] ->
/usr/lib/x86_64-linux-gnu/dovecot/libdovecot-storage.so.0(mailbox_get_open_status+0x68)
[0x7f553aae4a78] ->
/usr/lib/dovecot/modules/lib21_fts_squat_plugin.so(+0x3684)
[0x7f553677a684] ->
/usr/lib/dovecot/modules/lib21_fts_squat_plugin.so(+0x3820)
[0x7f553677a820] ->
/usr/lib/dovecot/modules/lib20_fts_plugin.so(fts_backend_lookup_multi+0x163)
[0x7f5539b016a3] ->
/usr/lib/dovecot/modules/lib20_fts_plugin.so(+0xd728)
[0x7f5539b06728] ->
/usr/lib/dovecot/modules/lib20_fts_plugin.so(fts_search_lookup+0xeb)
[0x7f5539b06bbb] ->
/usr/lib/dovecot/modules/lib20_fts_plugin.so(+0xf8b8)
[0x7f5539b088b8] -> dovecot/imap(imap_search_start+0x6a)
[0x5654cb5a0d6a] -> dovecot/imap(cmd_sort+0x293) [0x5654cb593553] ->
dovecot/imap(command_exec+0x64) [0x5654cb599874] ->
dovecot/imap(+0x1bd22) [0x5654cb597d22] -> dovecot/imap(+0x1bdbc)
[0x5654cb597dbc] -> dovecot/imap(client_handle_input+0x1b5)
[0x5654cb5981c5] -> dovecot/imap(client_input+0xa4) [0x5654cb5987e4]
->
/usr/lib/x86_64-linux-gnu/dovecot/libdovecot.so.0(io_loop_call_io+0x69)
[0x7f553a8174a9] ->
/usr/lib/x86_64-linux-gnu/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x12e)
[0x7f553a818d1e] ->
/usr/lib/x86_64-linux-gnu/dovecot/libdovecot.so.0(io_loop_handler_run+0x4c)
[0x7f553a8175ac] ->
/usr/lib/x86_64-linux-gnu/dovecot/libdovecot.so.0(io_loop_run+0x38)
[0x7f553a8177b8] ->
/usr/lib/x86_64-linux-gnu/dovecot/libdovecot.so.0(master_service_run+0x13)
[0x7f553a7940a3] -> dovecot/imap(main+0x339) [0x5654cb58a539] ->
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)
[0x7f553a375b97] -> dovecot/imap(_start+0x2a) [0x5654cb58a71a]
Mar 14 23:14:58 *** dovecot: service=imap, user=***, ip=[::1].
Fatal: master: service(imap): child 6436 killed with signal 6 (core
dumps disabled)
This is my config:
# 2.3.0.1 (ffd8a29): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.0.1 (d33dca20)
# OS: Linux 4.15.0-46-generic x86_64 Ubuntu 18.04.2 LTS ext4
auth_mechanisms = plain login digest-md5 cram-md5 apop
auth_username_chars =
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890&.-_@'
default_vsz_limit = 8096 M
disable_plaintext_auth = no
first_valid_uid = 30
imap_client_workarounds = delay-newmail
imap_logout_format = rcvd=%i, sent=%o
mail_home = /var/qmail/mailnames/%Ld/%Ln
mail_location = maildir:/var/qmail/mailnames/%Ld/%Ln/Maildir
mail_log_prefix = "service=%s, user=%u, ip=[%r]. "
mail_max_userip_connections = 100
mail_plugins = quota fts fts_squat virtual
managesieve_logout_format = rcvd=%i, sent=%o
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeri$
namespace inbox {
inbox = yes
location =
prefix = INBOX.
separator = .
}
namespace virtual {
hidden = no
inbox = no
list = yes
location =
virtual:/var/qmail/mailnames/%Ld/%Ln/virtual/:INDEX=/var/qmail/mailnames/%Ld/%Ln/virtual/
prefix =
separator = .
}
passdb {
driver = plesk
}
plugin {
fts = squat
fts_squat = partial=4 full=10
quota = maildir:User quota
quota_grace = 0
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
sieve_extensions = +notify +imapflags
}
pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
pop3_logout_format = rcvd=%i, sent=%o, top=%t/%p, retr=%r/%b,
del=%d/%m, size=%s
protocols = imap pop3 sieve
service auth-worker {
group =
user =
}
service auth {
group =
unix_listener auth-userdb {
group = popuser
mode = 0600
user = popuser
}
user =
}
service imap-login {
process_limit = 2048
service_count = 1
}
service imap {
process_limit = 2048
service_count = 1
}
service pop3-login {
Re: regarding ssl certificates
On 3/14/19 10:08 AM, Stephan von Krawczynski via dovecot wrote: Some facts for you, as obviously you have not understood what a CA is worth that is compromised by either hackers or "authorities". If you want to know more, read articles about closing of CA DigiNotar, like: https://en.wikipedia.org/wiki/DigiNotar I am well aware of what happens when a CA is compromised and man-in-the-middle attacks become possible. Your initial mail implied that the user's own keys would be compromised. Running your own CA is quite useless for asserting one's identity to random other mail servers as you'd have to get them all to trust you as a CA, with exactly the same problems as any other CA, with anonymity tacked on. DNSSEC would be wonderful if it was commonly supported, but we ain't there yet. The point is that a cert from any currently recognized cert authority is *operationally* better than a snakeoil cert. The practical impact of your initial advice is "don't run a mail server". Also, secrets don't last -- nobody trusts anything that came from DigiNotar. That will happen to any CA caught issuing bogus certs, regardless for whom. Then read US export laws concerning security devices. Then judge your US-issued certs... Totally orthogonal to the problem of mutual trust for mail handling.
Re: Re: regarding ssl certificates
(Sorry for the broken references, my MUA misplaced the e-mail I'm *actually* replying to.) On 03/14/2019 03:08 PM, Stephan von Krawczynski wrote: > Some facts for you, as obviously you have not understood what a CA is worth > that is compromised by either hackers or "authorities". > If you want to know more, read articles about closing of CA DigiNotar, like: > https://en.wikipedia.org/wiki/DigiNotar > > Then read US export laws concerning security devices. > Then judge your US-issued certs... Out of interest, does(*) or doesn't(**) your scenario include mechanisms like HPKP? (*) I'm not aware of any MUAs implementing one, just browsers, and it's now being phased out by *them* in favor of CT, too. (**) If not, the question of what CAs issued any *legit* certs for you has no practical relevance on whether and which other CAs may get hacked or judicially suborned into creating a working fraudulent one. (Where "practical" means "you cannot expect the entire, possibly worldwide, user population to manually strip their clients' list of accepted CAs down to the one *you* chose".) Regards, -- Jochen Bern Systemingenieur www.binect.de www.facebook.de/binect smime.p7s Description: S/MIME Cryptographic Signature
dovecot.conf "local hostname" uses only one resolved value
https://wiki.dovecot.org/SSL/DovecotConfiguration#Different_certificates_per_IP_and_protocol
says:
local 192.0.2.10 { # instead of IP you can also use hostname, which will
be resolved
However if the name resolves to multiple values only one is used.
Test.
Choose any name with multiple values, I created a local name:
$ nslookup multi.lan
Server: 127.0.0.1
Address:127.0.0.1#53
Name: multi.lan
Address: 192.168.1.2
Name: multi.lan
Address: 192.168.1.3
Name: multi.lan
Address: 192.168.1.1
Minimal dovecot.conf:
local multi.lan {
protocol imap {
ssl_cert = In my real case with A and records, only the record is used.
Testing with "openssl s_client -starttls imap ..." gives me the wrong
certificate for the IPv4 address. Workaround: specify all addresses and
do not use lookup.
James.
Re: Unable to set quota-fs plugin
Sure !! I got it ! I have connected with kmail, which keeps the imap opened and which has generated the error several times during the session. Please find attached the strace. Not sure this strace will help. I executed '/usr/libexec/dovecot/imap -u eric' and typed the same command as in the strace and it worked Could someone have a look in the strace and suggest some ideas to progress ? Thanks and best regards, - Eric Grammatico _/) 14 mars 2019 16:08 "Yassine Chaouche via dovecot" a écrit: > How I'd love if I could just launch dovecot (with symbols) in a debugger, set > a breakpoint in the > right function call, and login from Rainloop. Then I could run the process > one step at a time and > inspect everything... > > Yassine. > > On 3/14/19 3:59 PM, Eric Grammatico via dovecot wrote: > >> The error is generated when a user get connect from a client (RainLoop, a >> web UI). I don't know if >> the client request the quota or if it's automagically pushed from the imap >> process. I'd say the >> client requests. My problem is the process imap generating the error is >> launched just before and >> stopped right after the error is raised and thus quite difficult to trace >> the process. >> >> - >> Eric Grammatico _/) >> >> 14 mars 2019 15:46 "Yassine Chaouche via dovecot" a >> écrit: >>> On 3/14/19 3:40 PM, Eric Grammatico via dovecot wrote: >>> Hi there, Well.. I didn't find a way to strace imap. If I well understood, the faulty IMAP is launched by dovecot from or after a succesfull imap-login process. I have executed manually '/usr/libexec/dovecot/imap -u eric' and typed getquotaroot "INBOX" which didn't reproduce the error seen in the dovecot logs and reported the correct quota. Any idea how to find the imap command generating the error imap(eric)<3085>: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, /dev/vda1) failed: No such file or directory Thanks and regards, - Eric Grammatico _/) >>> >>> How did you get that error in the first place ? :p >>> >>> Yassine. dovecot_imap.strace Description: Binary data
Re: Unable to set quota-fs plugin
How I'd love if I could just launch dovecot (with symbols) in a debugger, set a breakpoint in the right function call, and login from Rainloop. Then I could run the process one step at a time and inspect everything... Yassine. On 3/14/19 3:59 PM, Eric Grammatico via dovecot wrote: The error is generated when a user get connect from a client (RainLoop, a web UI). I don't know if the client request the quota or if it's automagically pushed from the imap process. I'd say the client requests. My problem is the process imap generating the error is launched just before and stopped right after the error is raised and thus quite difficult to trace the process. - Eric Grammatico _/) 14 mars 2019 15:46 "Yassine Chaouche via dovecot" a écrit: On 3/14/19 3:40 PM, Eric Grammatico via dovecot wrote: Hi there, Well.. I didn't find a way to strace imap. If I well understood, the faulty IMAP is launched by dovecot from or after a succesfull imap-login process. I have executed manually '/usr/libexec/dovecot/imap -u eric' and typed getquotaroot "INBOX" which didn't reproduce the error seen in the dovecot logs and reported the correct quota. Any idea how to find the imap command generating the error imap(eric)<3085>: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, /dev/vda1) failed: No such file or directory Thanks and regards, - Eric Grammatico _/) How did you get that error in the first place ? :p Yassine.
Re: dovecot/config processes one more time - which are safe to kill?
On 14/01/2019 01:43, Timo Sirainen wrote: > On 13 Dec 2018, at 11.18, Arkadiusz Miśkiewicz wrote: >> >> >> Hello. >> >> The problem with dovecot/config processes never ending and spawning new >> one on each reload >> (https://www.dovecot.org/list/dovecot/2016-November/106058.html) is >> becoming a problem here: >> >> # ps aux|grep dovecot/config|wc -l >> 206 > > I think you also have 206 other Dovecot processes that are keeping the config > process open? Maybe 206 imap-login processes or something? Anyway I'd expect > that this would happen only if some other process is keeping a UNIX socket > connection open to the config process. Unless of course there's some bug that > just isn't shutting them down even though they don't have any connections.. > But at least I couldn't easily reproduce that. > > I suppose there isn't much of a reason for existing processes to keep the > config socket open after reload, so a patch like below would likely help. > Although it probably should be delayed so that existing imap/pop3-login > connections doing STARTTLS wouldn't fail if that causes a new config lookup. > > diff --git a/src/lib-master/master-service.c b/src/lib-master/master-service.c > index 3de11fa1b..41005cb5e 100644 > --- a/src/lib-master/master-service.c > +++ b/src/lib-master/master-service.c > @@ -815,6 +815,7 @@ void master_service_stop_new_connections(struct > master_service *service) > } > if (service->login != NULL) > master_login_stop(service->login); > + master_service_close_config_fd(service); > } > > bool master_service_is_killed(struct master_service *service) Wouldn't be it better if these other process simply reconnected to current config/stats/log processes? (I'm killing n-1 processes leaving youngest one alive) Hm, killing older "config" processes doesn't report that killed process was used by anything but likely this is logging behaviour difference only (between killing config/stats vs killing log (which reports thins like: Shutting down logging for 'imap-login: ' with 16 clients)) Mar 14 06:10:10 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 06:22:11 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 06:52:13 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 07:01:02 mailbox dovecot: config: Warning: Killed with signal 15 (by pid=4825 uid=0 code=kill) Mar 14 07:01:02 mailbox dovecot: config: Warning: Killed with signal 15 (by pid=4825 uid=0 code=kill) Mar 14 07:01:02 mailbox dovecot: config: Warning: Killed with signal 15 (by pid=4825 uid=0 code=kill) Mar 14 07:10:15 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 07:16:16 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 08:01:02 mailbox dovecot: config: Warning: Killed with signal 15 (by pid=20047 uid=0 code=kill) Mar 14 08:01:02 mailbox dovecot: config: Warning: Killed with signal 15 (by pid=20047 uid=0 code=kill) Mar 14 08:28:21 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 08:32:17 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 08:44:16 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 08:56:17 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 09:01:04 mailbox dovecot: config: Warning: Killed with signal 15 (by pid=31423 uid=0 code=kill) Mar 14 09:01:04 mailbox dovecot: config: Warning: Killed with signal 15 (by pid=31423 uid=0 code=kill) Mar 14 09:01:04 mailbox dovecot: config: Warning: Killed with signal 15 (by pid=31423 uid=0 code=kill) Mar 14 09:01:04 mailbox dovecot: config: Warning: Killed with signal 15 (by pid=31423 uid=0 code=kill) Mar 14 11:00:22 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 11:01:02 mailbox dovecot: config: Warning: Killed with signal 15 (by pid=31710 uid=0 code=kill) Mar 14 11:02:22 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 11:08:21 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 11:40:20 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 12:01:02 mailbox dovecot: config: Warning: Killed with signal 15 (by pid=3995 uid=0 code=kill) Mar 14 12:01:02 mailbox dovecot: config: Warning: Killed with signal 15 (by pid=3995 uid=0 code=kill) Mar 14 12:01:02 mailbox dovecot: config: Warning: Killed with signal 15 (by pid=3995 uid=0 code=kill) Mar 14 12:06:19 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 12:16:21 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 12:36:20 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14 12:52:17 mailbox dovecot: master: Warning: SIGHUP received - reloading configuration Mar 14
Re: Unable to set quota-fs plugin
The error is generated when a user get connect from a client (RainLoop, a web UI). I don't know if the client request the quota or if it's automagically pushed from the imap process. I'd say the client requests. My problem is the process imap generating the error is launched just before and stopped right after the error is raised and thus quite difficult to trace the process. - Eric Grammatico _/) 14 mars 2019 15:46 "Yassine Chaouche via dovecot" a écrit: > On 3/14/19 3:40 PM, Eric Grammatico via dovecot wrote: > >> Hi there, >> >> Well.. I didn't find a way to strace imap. If I well understood, the faulty >> IMAP is launched by >> dovecot from or after a succesfull imap-login process. I have executed >> manually >> '/usr/libexec/dovecot/imap -u eric' and typed getquotaroot "INBOX" which >> didn't reproduce the error >> seen in the dovecot logs and reported the correct quota. >> >> Any idea how to find the imap command generating the error >> >> imap(eric)<3085>: Error: Failed to get quota resource >> STORAGE: quota-fs: >> quotactl(Q_GETQUOTA, /dev/vda1) failed: No such file or directory >> >> Thanks and regards, >> - >> Eric Grammatico _/) > > How did you get that error in the first place ? :p > > Yassine.
Re: Quota questions
Yes, filesystem quotas.
On 14/03/2019 16:55, Peter Hudec via dovecot wrote:
Hi,
by XFS do you mean filesystem quotas, yes ?
regards
Peter
On 14 Mar 2019, at 15:19, Edgaras Lukoševičius via dovecot
wrote:
I was fighting domain quota for a long time, too. And I was never really
successful at it, because group/domain quotas have multiple problems, and
domain quota recalc is just one of them :)
After a long trial and error I ended up implementing XFS project quotas.
On 14/03/2019 15:14, Peter Hudec via dovecot wrote:
Hi all,
I’m a little bit confused about the quota plugin in dovecot and fighting the
the issues the people had years ago. I spent readingg the old archives and the
mailing list for 3 days and not able to get work some features. Single user
quota is fine and simple, the group quota /for example domain based/ makes me
unhappy.
Setup: CentOS7, dovecot comunity repo, dovecot 2.3.5
1) domain quota recalc
domain quota recalc do not work properly. The domain qouta usage is worknig
well, hwhen receiving/deleting mail, generaly if the operations are incremental.
But if I run domain quota recalc, the doveadm is setting the domain quota after
each user calculation, that means the domain quota is set to the last user.
2) multiple quota roots and rules
According the documentation, there could be possible, from the sample
configuration file
# Multiple quota roots are also possible, for example this gives each user
# their own 100MB quota and one shared 1GB quota within the domain
plugin {
quota = dict:User quota::proxy::quota
quota2 = dict:Group quota:%d:proxy::quota_domain
quota_rule = *:storage=1024M
quota2_rule = *:storage=2048M
}
But If I run
[TEST] r...@mail-store01.test.host.sk: /etc/dovecot # doveadm quota get -u '*'
UsernameQuota name TypeValue Limit
%
tes...@test.host.sk User quota STORAGE 1 1024
0
tes...@test.host.sk User quota MESSAGE 1 -
0
tes...@test.host.sk Group quota STORAGE 7 -
0
tes...@test.host.sk Group quota MESSAGE 3 -
0
tes...@test.host.sk User quota STORAGE 7 1024
0
tes...@test.host.sk User quota MESSAGE 3 -
0
tes...@test.host.sk Group quota STORAGE 7 -
0
tes...@test.host.sk Group quota MESSAGE 3 -
0
The idea is to have overall domain quota, but for user able to set it’s
personal quota.
regards
Peter
Re: Quota questions
Hi,
by XFS do you mean filesystem quotas, yes ?
regards
Peter
> On 14 Mar 2019, at 15:19, Edgaras Lukoševičius via dovecot
> wrote:
>
> I was fighting domain quota for a long time, too. And I was never really
> successful at it, because group/domain quotas have multiple problems, and
> domain quota recalc is just one of them :)
>
> After a long trial and error I ended up implementing XFS project quotas.
>
> On 14/03/2019 15:14, Peter Hudec via dovecot wrote:
>> Hi all,
>>
>> I’m a little bit confused about the quota plugin in dovecot and fighting the
>> the issues the people had years ago. I spent readingg the old archives and
>> the mailing list for 3 days and not able to get work some features. Single
>> user quota is fine and simple, the group quota /for example domain based/
>> makes me unhappy.
>>
>> Setup: CentOS7, dovecot comunity repo, dovecot 2.3.5
>>
>>
>> 1) domain quota recalc
>> domain quota recalc do not work properly. The domain qouta usage is worknig
>> well, hwhen receiving/deleting mail, generaly if the operations are
>> incremental.
>> But if I run domain quota recalc, the doveadm is setting the domain quota
>> after each user calculation, that means the domain quota is set to the last
>> user.
>>
>> 2) multiple quota roots and rules
>> According the documentation, there could be possible, from the sample
>> configuration file
>>
>> # Multiple quota roots are also possible, for example this gives each user
>> # their own 100MB quota and one shared 1GB quota within the domain
>>
>> plugin {
>> quota = dict:User quota::proxy::quota
>> quota2 = dict:Group quota:%d:proxy::quota_domain
>> quota_rule = *:storage=1024M
>> quota2_rule = *:storage=2048M
>> }
>>
>>
>> But If I run
>> [TEST] r...@mail-store01.test.host.sk: /etc/dovecot # doveadm quota get -u
>> '*'
>> UsernameQuota name TypeValue Limit
>>%
>> tes...@test.host.sk User quota STORAGE 1 1024
>>0
>> tes...@test.host.sk User quota MESSAGE 1 -
>>0
>> tes...@test.host.sk Group quota STORAGE 7 -
>>0
>> tes...@test.host.sk Group quota MESSAGE 3 -
>>0
>> tes...@test.host.sk User quota STORAGE 7 1024
>>0
>> tes...@test.host.sk User quota MESSAGE 3 -
>>0
>> tes...@test.host.sk Group quota STORAGE 7 -
>>0
>> tes...@test.host.sk Group quota MESSAGE 3 -
>>0
>>
>> The idea is to have overall domain quota, but for user able to set it’s
>> personal quota.
>>
>> regards
>> Peter
Re: Unable to set quota-fs plugin
On 3/14/19 3:40 PM, Eric Grammatico via dovecot wrote: Hi there, Well.. I didn't find a way to strace imap. If I well understood, the faulty IMAP is launched by dovecot from or after a succesfull imap-login process. I have executed manually '/usr/libexec/dovecot/imap -u eric' and typed getquotaroot "INBOX" which didn't reproduce the error seen in the dovecot logs and reported the correct quota. Any idea how to find the imap command generating the error imap(eric)<3085>: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, /dev/vda1) failed: No such file or directory Thanks and regards, - Eric Grammatico _/) How did you get that error in the first place ? :p Yassine.
Re: Unable to set quota-fs plugin
Hi there,
Well.. I didn't find a way to strace imap. If I well understood, the faulty
IMAP is launched by dovecot from or after a succesfull imap-login process. I
have executed manually '/usr/libexec/dovecot/imap -u eric' and typed
getquotaroot "INBOX" which didn't reproduce the error seen in the dovecot logs
and reported the correct quota.
Any idea how to find the imap command generating the error
imap(eric)<3085>: Error: Failed to get quota resource
STORAGE: quota-fs: quotactl(Q_GETQUOTA, /dev/vda1) failed: No such file or
directory
Thanks and regards,
-
Eric Grammatico _/)
14 mars 2019 11:46 "Eric Grammatico" a écrit:
> I use sendmail and quota-status is not running in background.
>
> Fully aligned with you about focusing on imap... will try to get other strace
> and report there.
>
> thanks and regards,
>
> -
> Eric Grammatico _/)
>
> 14 mars 2019 11:37 "Yassine Chaouche via dovecot" a
> écrit:
>
>> On 3/14/19 9:53 AM, Yassine Chaouche via dovecot wrote:
>>
>>> On 3/13/19 2:10 PM, Eric Grammatico via dovecot wrote:
Thanks Aki,
Please find attached strace for imap and quota-status which report an >>
error at the end.
Regards,
>>>
>>> write(2, "/usr/libexec/dovecot/quota-statu"..., >
>>> 57/usr/libexec/dovecot/quota-status: invalid
>>> option -- 'u'
>>>
>>> Please retry with the good options (-u is invalid)
>>>
>>> Yassine.
>>
>> Ah, that seems to be the service that is called by the MTA before delivering
>> the mail to the LDA,
>> in case the user is over quota, so that the MTA may bounce the e-mail right
>> away instead of
>> accepting it first then bouncing afterwards (after the LDA refuses the
>> message).
>>
>> But according to the error message you posted on your first e-mail, the
>> error happens with imap, I
>> don't know if quota-status is involved here (might be) ?
>>
>> In any case, I would concentrate on imap and not quota-status. Nothing in
>> the imap strace shows any
>> trace of errors. Particulary, I was looking for a quotactl line in the
>> strace, but I couldn't find
>> it.
>>
>> In the other hand, it is present in the doveadm quota strace, and has
>> completed successfully
>>
>> dovecot.strace:quotactl(QCMD(Q_GETQUOTA, USRQUOTA), "/dev/vda1", 1000,
>> {dqb_bhardlimit=4194304,
>> dqb_bsoftlimit=3170304, dqb_curspace=638853120, dqb_ihardlimit=0,
>> dqb_isoftlimit=0,
>> dqb_curinodes=12784, ...}) = 0
>>
>> Someone has to tell us under what conditions will the imap daemon check for
>> quota (at login ? at
>> delivery or any other action involving moving mail around like copying or
>> expunging ?)
>>
>> For the quota-status libexec, I have set it to run with quota-status -f
>> postfix but your setup may
>> vary (if it's every configured). If it is running, you can just grep it's
>> pid with pgrep
>> quota-status then strace -p $PID and see how it behaves (wait until a quota
>> operation is needed).
>>
>> Yassine.
Re: Quota questions
I was fighting domain quota for a long time, too. And I was never really
successful at it, because group/domain quotas have multiple problems,
and domain quota recalc is just one of them :)
After a long trial and error I ended up implementing XFS project quotas.
On 14/03/2019 15:14, Peter Hudec via dovecot wrote:
Hi all,
I’m a little bit confused about the quota plugin in dovecot and fighting the
the issues the people had years ago. I spent readingg the old archives and the
mailing list for 3 days and not able to get work some features. Single user
quota is fine and simple, the group quota /for example domain based/ makes me
unhappy.
Setup: CentOS7, dovecot comunity repo, dovecot 2.3.5
1) domain quota recalc
domain quota recalc do not work properly. The domain qouta usage is worknig
well, hwhen receiving/deleting mail, generaly if the operations are incremental.
But if I run domain quota recalc, the doveadm is setting the domain quota after
each user calculation, that means the domain quota is set to the last user.
2) multiple quota roots and rules
According the documentation, there could be possible, from the sample
configuration file
# Multiple quota roots are also possible, for example this gives each user
# their own 100MB quota and one shared 1GB quota within the domain
plugin {
quota = dict:User quota::proxy::quota
quota2 = dict:Group quota:%d:proxy::quota_domain
quota_rule = *:storage=1024M
quota2_rule = *:storage=2048M
}
But If I run
[TEST] r...@mail-store01.test.host.sk: /etc/dovecot # doveadm quota get -u '*'
UsernameQuota name TypeValue Limit
%
tes...@test.host.sk User quota STORAGE 1 1024
0
tes...@test.host.sk User quota MESSAGE 1 -
0
tes...@test.host.sk Group quota STORAGE 7 -
0
tes...@test.host.sk Group quota MESSAGE 3 -
0
tes...@test.host.sk User quota STORAGE 7 1024
0
tes...@test.host.sk User quota MESSAGE 3 -
0
tes...@test.host.sk Group quota STORAGE 7 -
0
tes...@test.host.sk Group quota MESSAGE 3 -
0
The idea is to have overall domain quota, but for user able to set it’s
personal quota.
regards
Peter
Re: regarding ssl certificates
On Thu, 14 Mar 2019 09:51:14 -0400 Phil Turmel via dovecot wrote: > On 3/14/19 7:40 AM, Stephan von Krawczynski via dovecot wrote: > > > Sorry I have to write this, but this is again pointing people in a fake > > security direction. > > You should be sorry, because you are wrong. > > > The only valid authority for a certificate is the party using it. Any third > > party with unknown participants cannot be a "Certificate Authority" in its > > true sense. This is why you should see "Let's Encrypt" simply as a cheap > > way to fake security. It is a US entity, which means it _must_ hand out all > > necessary keys to fake certificates to the US authorities _by law_. > > Certificate authorities, including Let's Encrypt, operate on Certificate > Signing Requests, not Private Keys. Some CAs do offer private key > generation in their services for the user's convenience, but it is not > recommended (obviously) and in no way required. Getting a CA to sign a > CSR in no way exposes keys to that CA, and therefore not to any government. > > While there are weakness in the CA trust system, they aren't anything > related to replacing a snakeoil cert with one from Let's Encrypt. > > [rest of ignorant rant trimmed] Some facts for you, as obviously you have not understood what a CA is worth that is compromised by either hackers or "authorities". If you want to know more, read articles about closing of CA DigiNotar, like: https://en.wikipedia.org/wiki/DigiNotar Then read US export laws concerning security devices. Then judge your US-issued certs... > Phil -- MfG, Stephan von Krawczynski -- ith Kommunikationstechnik GmbH Lieferanschrift : Reiterstrasse 24, D-94447 Plattling Telefon : +49 9931 9188 0 Fax : +49 9931 9188 44 Geschaeftsfuehrer: Stephan von Krawczynski Registergericht : Deggendorf HRB 1625 --
Re: dovecot-keywords are not preserved any more when moving mails between folders
Hi Timo, hi list, On 12.03.19 22:31, Timo Sirainen via dovecot wrote: On 12 Mar 2019, at 17.55, Dan Christensen via dovecot wrote: On Mar 12, 2019, Aki Tuomi via dovecot wrote: On 12.3.2019 13.46, Piper Andreas via dovecot wrote: after an upgrade of dovecot-2.2.5 to dovecot-2.3.4 the dovecot-keywords, which in my case are set by thunderbird, are not preserved any more when moving a mail between folders. We are aware of this bug, and it's being tracked as DOP-842. Could this bug also be causing flags to be lost when using dsync (as I described in some messages to this list Feb 16 to 23)? It seems like it might be a different bug, since in my experience the flags are sometimes synced and then removed later. That bug is fixed with attached patch. This patch seems to fix my "replication dropped imap flags" issue reported on this list on 2018-11-26! Thank you! Best regards, -- Patrick Cernko +49 681 9325 5815 Joint Administration: Information Services and Technology Max-Planck-Institute fuer Informatik & Softwaresysteme smime.p7s Description: S/MIME Cryptographic Signature
Re: replication dropped imap flags
Update: The patch "dsync: Fix importing keywords with MAIL_TRANSACTION_SYNC flag set" mentioned in the mail from Timo Sirainen on 2019-03-12 22:31 on this list seems to fix this issue. Regards, -- Patrick Cernko +49 681 9325 5815 Joint Administration: Information Services and Technology Max-Planck-Institute fuer Informatik & Softwaresysteme smime.p7s Description: S/MIME Cryptographic Signature
Re: regarding ssl certificates
On 3/14/19 7:40 AM, Stephan von Krawczynski via dovecot wrote: Sorry I have to write this, but this is again pointing people in a fake security direction. You should be sorry, because you are wrong. The only valid authority for a certificate is the party using it. Any third party with unknown participants cannot be a "Certificate Authority" in its true sense. This is why you should see "Let's Encrypt" simply as a cheap way to fake security. It is a US entity, which means it _must_ hand out all necessary keys to fake certificates to the US authorities _by law_. Certificate authorities, including Let's Encrypt, operate on Certificate Signing Requests, not Private Keys. Some CAs do offer private key generation in their services for the user's convenience, but it is not recommended (obviously) and in no way required. Getting a CA to sign a CSR in no way exposes keys to that CA, and therefore not to any government. While there are weakness in the CA trust system, they aren't anything related to replacing a snakeoil cert with one from Let's Encrypt. [rest of ignorant rant trimmed] Phil
Quota questions
Hi all,
I’m a little bit confused about the quota plugin in dovecot and fighting the
the issues the people had years ago. I spent readingg the old archives and the
mailing list for 3 days and not able to get work some features. Single user
quota is fine and simple, the group quota /for example domain based/ makes me
unhappy.
Setup: CentOS7, dovecot comunity repo, dovecot 2.3.5
1) domain quota recalc
domain quota recalc do not work properly. The domain qouta usage is worknig
well, hwhen receiving/deleting mail, generaly if the operations are incremental.
But if I run domain quota recalc, the doveadm is setting the domain quota after
each user calculation, that means the domain quota is set to the last user.
2) multiple quota roots and rules
According the documentation, there could be possible, from the sample
configuration file
# Multiple quota roots are also possible, for example this gives each user
# their own 100MB quota and one shared 1GB quota within the domain
plugin {
quota = dict:User quota::proxy::quota
quota2 = dict:Group quota:%d:proxy::quota_domain
quota_rule = *:storage=1024M
quota2_rule = *:storage=2048M
}
But If I run
[TEST] r...@mail-store01.test.host.sk: /etc/dovecot # doveadm quota get -u '*'
UsernameQuota name TypeValue Limit
%
tes...@test.host.sk User quota STORAGE 1 1024
0
tes...@test.host.sk User quota MESSAGE 1 -
0
tes...@test.host.sk Group quota STORAGE 7 -
0
tes...@test.host.sk Group quota MESSAGE 3 -
0
tes...@test.host.sk User quota STORAGE 7 1024
0
tes...@test.host.sk User quota MESSAGE 3 -
0
tes...@test.host.sk Group quota STORAGE 7 -
0
tes...@test.host.sk Group quota MESSAGE 3 -
0
The idea is to have overall domain quota, but for user able to set it’s
personal quota.
regards
Peter
Re: flags not synced correctly with dovecot sync (dsync)
On Mar 14, 2019, Timo Sirainen via dovecot wrote:
> Looks like you're also using Maildir, which has another bug of
> keywords not being copied correctly.
Yes, I'm using Maildir. I'm not sure your description matches the
bug, though. In my case, the flags are copied, but in the wrong
direction when doing a sync. More precisely, the flag change is
correctly copied the first time, but then reversed by later syncs.
So it seems to be something in the sync logic. I'll include below
the original message, which includes steps to reproduce the problem.
I've now got a set-up where I can conveniently test patches, so
let me know you'd like me to test something.
Dan
I'm running dovecot 2.3.4.1 from https://repo.dovecot.org/ on Ubuntu
18.04 on three machines that I'll call server, laptop1 and laptop2.
Both laptop1 and laptop2 run dovecot sync against server to keep local
copies of my imap folders. Even when I initially had only two machines,
laptop1 and server, I occasionally noticed that flags were lost, usually
custom flags used by Gnus, but I couldn't reliably reproduce the
problem.
Now that I have two laptops syncing against the server, the problem has
gotten worse and I figured out a way to reproduce it:
- on server: create new IMAP folder test, and put two read messages in it
- on laptop1: doveadm sync -u user -l 10 -m test -f user@server
- on laptop2: doveadm sync -u user -l 10 -m test -f user@server
At this point, all three machines show the two messages M1 and M2
as being read.
- on laptop1: mark message M1 unread
- on laptop2: mark message M2 unread
- on laptop1: doveadm sync -u user -l 10 -m test -f user@server
Both laptop1 and server have M1 unread, M2 read, as expected.
- on laptop2: doveadm sync -u user -l 10 -m test -f user@server
Now laptop2 and server have M1 *read*, M2 unread.
- on laptop1: doveadm sync -u user -l 10 -m test -f user@server
Now laptop1 and the server have both M1 and M2 *read*.
- on laptop2: doveadm sync -u user -l 10 -m test -f user@server
Now laptop2 has both read as well.
The two lines that say "*read*" are wrong in my opinion. dsync
propagated a read mark to an unread message, even though that message
was marked unread more recently than it was marked read.
I usually use stateful sync, and get many related problems.
I just did a test in which M1 and M2 started out read, and I
started with empty files named dstate.test on laptop1 and laptop2.
Then I did the above procedure, using the command
doveadm sync -u user -l 10 -m test -s "`cat dstate.test`" user@server >
dstate.test
At the end, laptop2 and server had both messages unread (which is good),
but laptop1 had only M1 unread, and repeated runs of the sync command
did not correct this. So the stateful sync failed to detect a change.
Are these bugs in dovecot? Is there more information that I can
provide? The output of doveconf -n on one machine is below, and
the others are almost identical.
Thanks for any help!
Dan
# 2.3.4.1 (3c0b8769e): /etc/dovecot/dovecot.conf
# OS: Linux 4.15.0-45-generic x86_64 Ubuntu 18.04.1 LTS
# Hostname: laptop2
auth_mechanisms = plain login
listen = 127.0.0.1
mail_index_log2_max_age = 10 days
mail_index_log_rotate_min_age = 1 days
mail_index_log_rotate_min_size = 300 k
mail_location = maildir:~/Maildir
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
args = scheme=CRYPT username_format=%u /etc/dovecot/users
driver = passwd-file
}
protocols = imap
service imap-login {
inet_listener imap {
address = *
port = 143
}
inet_listener imaps {
address = *
port = 943
ssl = yes
}
}
service imap {
process_limit = 25
}
ssl_cert =
Re: regarding ssl certificates
On Thu, Mar 14, 2019, at 2:51 PM, Nikolai Lusan via dovecot wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> So this question means you need to do some more reading about all SSL/TLS
> services.
>
> On Thu, 2019-03-14 at 10:46 +, mick crane via dovecot wrote:
> > Excuse dopey question.
> > I'm not exactly clear about certificates.
> > Apache2 default install has this snake oil certificate
> > Can make a new one for apache
> > Can make one for dovecot
> > Can make one for ssl
> > Is there supposed to be the one (self signed ) certificate pair in one
> > place for the machine that each process hands out ?
> > Can they be moved to another machine ?
>
> In general you can have one certificate per hostname ('host.domain.com'),
> or you can have a wildcard certificate that is valid for
> '*.example.domain'.
Or you can use one cert with additional hostnames (domains) in that single
cert's subjectAltName's.
> The alternative to paid signed certificates is using letsencrypt
> https://letsencrypt.org - they can do both individual certificates and
> wildcard certificates.
With letsencrypt these (single cert with subjectAltName's) are easier to
validate than wildcards IIRC (http based vs. DNS based validation).
-- K
Re: regarding ssl certificates
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
So this question means you need to do some more reading about all SSL/TLS
services.
On Thu, 2019-03-14 at 10:46 +, mick crane via dovecot wrote:
> Excuse dopey question.
> I'm not exactly clear about certificates.
> Apache2 default install has this snake oil certificate
> Can make a new one for apache
> Can make one for dovecot
> Can make one for ssl
> Is there supposed to be the one (self signed ) certificate pair in one
> place for the machine that each process hands out ?
> Can they be moved to another machine ?
In general you can have one certificate per hostname ('host.domain.com'),
or you can have a wildcard certificate that is valid for
'*.example.domain'. The "snakeoil" certificates that you refer to are
generally self signed certificates, and yes you can create as many self
signed certs as you want. You can pay someone to sign your certificates for
you (wildcards may, or may not, be more cost effective in this case. They
are certainly more portable). Signed certificates should match the
hostnames they are used for, this is where wildcard certificates are of
use. The alternative to paid signed certificates is using letsencrypt
https://letsencrypt.org - they can do both individual certificates and
wildcard certificates.
There are pro's and con's for both paid and free signed certificates, but
you should use _a_ signed certificate for any TLS based service that
communicates with anything in the wild (i.e. non-internal services, public
mail servers, public web servers). Personally I use letsencrypt wildcards
with domain based authentication for automatic certificate renewal
(although distributing the certificates across servers can be an
"interesting" problem to deal with).
- --
Nikolai Lusan
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAlyKP/gACgkQ4ZaDRV2V
L6TswQ/9ERKEwSyy0aN0rS9axIB8bd5oGKBr3UhYY/rdsHaKj/c2PzbPHSoeyGFp
89ZRDChzrkwMqdDJTSzxYVA0+C4Vak0OKf3SUvHwCGdX4O2MDfPHXw5+4YDftjgn
oSaW2RmKmIQvfK8qKg4n8C+xDif54/20MwZaytSG/y7NikOt+3T8ph3UAO+HBD4G
7DMA/MKn0XX6pU8uhEbovU2ne4uUgl5FnncMcY9ibm8/4eEsqO5SU8DMwZtPG8Ux
4bPejIKf/L/5sFJw2wHI9vld3NTebklIK1eK1Vgw7en9Fmt/ydn+JXvxtDQa7YZS
gp0fN8r5SMiClrOvFkZVS3oJo2lklq+KJsMaD14l52HKmHZXNBUpZQI8dk/J+Q7c
m3liElPdTbZ+DK5c9koQqB8w49JfqWV9JFHhgY5WEntLvROarSOKn3GHy0DkDa6c
W2cQY8aOMM8FHsIqhsM0gKsNe8Q2aHPM/UoNJaWBrhoXnT/lEzUN3FNIbq7yj4cb
wXGQzZeFpcCaIb5SvMUl9yl8THZ2DpWsIFJOqYOmWMf1iiKLWu6bAh61sNYBWePQ
S+pwk55AOGQUf73ElpGBCJOjrLgt/ADIluNkO1fI9bKQQjSIQRfEX5LWQPLwz8z8
Z+cyZc2ufW6F+F13n1yHSFEYFwbjAIdM06dATbsrlNh7PyNYeFE=
=w9R4
-END PGP SIGNATURE-
Re: regarding ssl certificates
On Thu, 14 Mar 2019 12:13:15 +0100 "Guido Goluke, MajorLabel via dovecot" wrote: > Op 14-03-19 om 11:46 schreef mick crane via dovecot: > > Excuse dopey question. > > I'm not exactly clear about certificates. > > Apache2 default install has this snake oil certificate > > Can make a new one for apache > > Can make one for dovecot > > Can make one for ssl > > Is there supposed to be the one (self signed ) certificate pair in one > > place for the machine that each process hands out ? > > Can they be moved to another machine ? > > > > mick > > > > Apache, dovecot and Postfix can all use the same certificate, you do > need to configure each one to the location of the certificate though. > SSL is something else: apache, dovecot, postfix are all > services/programs. SSL is a protocol/way of encryption. Self-signed > means there is no Certificate Authority backing the legitimacy. Getting > a Let's Encrypt certificate (I recommend certbot) will get you a > legitime certificate, but only for the hostname (e.g. > web01.yourdomain.com) you provide it. This must be traceable to your > machine through DNS, so moving it to another machine would only work if > that machine would completely replace the old machine (domain name) and > the DNS is changed to point to your new IP address (or the old machine > gets taken out of 'the air' and the new machine gets the old one's IP > address). > > Best. > > MajorLabel Sorry I have to write this, but this is again pointing people in a fake security direction. The only valid authority for a certificate is the party using it. Any third party with unknown participants cannot be a "Certificate Authority" in its true sense. This is why you should see "Let's Encrypt" simply as a cheap way to fake security. It is a US entity, which means it _must_ hand out all necessary keys to fake certificates to the US authorities _by law_. Now probably you can imagine why they are giving the certificates out for free. US authorities can compromise all of them - without any "open knowledge". It would be dead easy to prevent this fake for the guys at mozilla or google (for the web), but they don't. All that is needed is a trivial DNS-based way to check self-signed certificates at the corresponding domain, let's say some host pointed to by a SRV entry. If you think DNS (not DNSSEC which has the same immanent problem) can be compromised too, well, yes, but then the access to hosts in that domain will be compromised anyway and a certificate will not save you at all. -- Regards, Stephan
Re: Am I right to assume certificate renewal with the same filename requires a dovecot reload/restart
Hi Yassine, hi Kostya, On 14.03.19 10:17, Kostya Vasilyev via dovecot wrote: On Thu, Mar 14, 2019, at 12:09 PM, Yassine Chaouche via dovecot wrote: On 3/14/19 9:55 AM, Patrick Cernko via dovecot wrote: [...] the way we have configured exim, it neither needs reload or restart but reads the certificate file every time it has to use it. What happens if you goof off in the middle of an opeartion, temporarily putting a wrong file instead of the new certificate, and exim starts delivering the new broken certificate right away ? or breaks ? or clients can't connect anymore with TLS ? or don't connect at all if you don't allow non-TLS connexions ? First: It happens the same if I replace the file with a wrong cert AND reload another service deamon and then get interupted. Second: I use ansible to push configurations and usually first push changes to a test system or only one machine. Third: Server administration always has the risk of human error ;-) Getting caught in the middle of a cert file or key file update should not happen -- a process that already opened a file will continue to be reading from that file, even if it gets renamed. But what if exim (or some other process) happens to read the "old" certificate file - and then the "new" private key file (or vice versa)? A race condition like this seems unlikely but technically possible. We store cert and key together in one PEM file, thus we will always exchange both cert and key in one "atomic" operation. Best, -- Patrick Cernko +49 681 9325 5815 Joint Administration: Information Services and Technology Max-Planck-Institute fuer Informatik & Softwaresysteme smime.p7s Description: S/MIME Cryptographic Signature
Re: regarding ssl certificates
Op 14-03-19 om 11:46 schreef mick crane via dovecot: Excuse dopey question. I'm not exactly clear about certificates. Apache2 default install has this snake oil certificate Can make a new one for apache Can make one for dovecot Can make one for ssl Is there supposed to be the one (self signed ) certificate pair in one place for the machine that each process hands out ? Can they be moved to another machine ? mick Apache, dovecot and Postfix can all use the same certificate, you do need to configure each one to the location of the certificate though. SSL is something else: apache, dovecot, postfix are all services/programs. SSL is a protocol/way of encryption. Self-signed means there is no Certificate Authority backing the legitimacy. Getting a Let's Encrypt certificate (I recommend certbot) will get you a legitime certificate, but only for the hostname (e.g. web01.yourdomain.com) you provide it. This must be traceable to your machine through DNS, so moving it to another machine would only work if that machine would completely replace the old machine (domain name) and the DNS is changed to point to your new IP address (or the old machine gets taken out of 'the air' and the new machine gets the old one's IP address). Best. MajorLabel
Re: regarding ssl certificates
On 3/14/19 11:46 AM, mick crane via dovecot wrote: Excuse dopey question. I'm not exactly clear about certificates. Apache2 default install has this snake oil certificate Can make a new one for apache Can make one for dovecot Can make one for ssl Is there supposed to be the one (self signed ) certificate pair in one place for the machine that each process hands out ? Can they be moved to another machine ? mick Not a dovecot specific question, but I use the same certificate for apache, dovecot and postfix, for my domain name, on any number of machines, except they must all have the same hostname (they don't all have the same name at the same time). I see no difference between a self-signed certificate and a broken certificate. In both cases you have warnings in the browser/mail client. In both cases you need to hit the "accept anyway" button. Yassine.
regarding ssl certificates
Excuse dopey question. I'm not exactly clear about certificates. Apache2 default install has this snake oil certificate Can make a new one for apache Can make one for dovecot Can make one for ssl Is there supposed to be the one (self signed ) certificate pair in one place for the machine that each process hands out ? Can they be moved to another machine ? mick -- Key IDC7D6E24C
Re: Unable to set quota-fs plugin
On 3/14/19 9:53 AM, Yassine Chaouche via dovecot wrote:
On 3/13/19 2:10 PM, Eric Grammatico via dovecot wrote:
Thanks Aki,
Please find attached strace for imap and quota-status which report an
error at the end.
Regards,
write(2, "/usr/libexec/dovecot/quota-statu"...,
57/usr/libexec/dovecot/quota-status: invalid option -- 'u'
Please retry with the good options (-u is invalid)
Yassine.
Ah, that seems to be the service that is called by the MTA before
delivering the mail to the LDA, in case the user is over quota, so that
the MTA may bounce the e-mail right away instead of accepting it first
then bouncing afterwards (after the LDA refuses the message).
But according to the error message you posted on your first e-mail, the
error happens with imap, I don't know if quota-status is involved here
(might be) ?
In any case, I would concentrate on imap and not quota-status. Nothing
in the imap strace shows any trace of errors. Particulary, I was looking
for a quotactl line in the strace, but I couldn't find it.
In the other hand, it is present in the doveadm quota strace, and has
completed successfully
dovecot.strace:quotactl(QCMD(Q_GETQUOTA, USRQUOTA), "/dev/vda1", 1000,
{dqb_bhardlimit=4194304, dqb_bsoftlimit=3170304, dqb_curspace=638853120,
dqb_ihardlimit=0, dqb_isoftlimit=0, dqb_curinodes=12784, ...}) = 0
Someone has to tell us under what conditions will the imap daemon check
for quota (at login ? at delivery or any other action involving moving
mail around like copying or expunging ?)
For the quota-status libexec, I have set it to run with quota-status -f
postfix but your setup may vary (if it's every configured). If it is
running, you can just grep it's pid with pgrep quota-status then strace
-p $PID and see how it behaves (wait until a quota operation is needed).
Yassine.
Re: Am I right to assume certificate renewal with the same filename requires a dovecot reload/restart
On Thu, Mar 14, 2019, at 12:09 PM, Yassine Chaouche via dovecot wrote: > On 3/14/19 9:55 AM, Patrick Cernko via dovecot wrote: > > > [...] the way we have configured exim, it neither needs reload or > > restart but reads the certificate file every time it has to use it. > > What happens if you goof off in the middle of an opeartion, temporarily > putting a wrong file instead of the new certificate, and exim starts > delivering the new broken certificate right away ? or breaks ? or > clients can't connect anymore with TLS ? or don't connect at all if you > don't allow non-TLS connexions ? > > Yassine. > > Getting caught in the middle of a cert file or key file update should not happen -- a process that already opened a file will continue to be reading from that file, even if it gets renamed. But what if exim (or some other process) happens to read the "old" certificate file - and then the "new" private key file (or vice versa)? A race condition like this seems unlikely but technically possible. -- K
Re: Am I right to assume certificate renewal with the same filename requires a dovecot reload/restart
On Thu, Mar 14, 2019, at 11:33 AM, Yassine Chaouche via dovecot wrote: On 3/14/19 9:32 AM, Yassine Chaouche via dovecot wrote: The general answere here is try and see, as you could totally test it on your own. The certificate is read at startup and put in memory for the rest of the execution time. Dovecot won't monitor the file for changes on disk, as this would waste CPU cycles and make dovecot only slower for no reason. The process (or person) that changes the file is responsible to restart dovecot to reload the new certificate in memory. Yassine. I should mention that this is also true for Apache and postfix. Yassine. Certbot has a feature to run scripts when renewing / deploying certificates. https://certbot.eff.org/docs/using.html#renewing-certificates Certbot also looks for these scripts under /etc/letsencrypt/renewal-hooks/pre post deploy FWIW here is my script restart.sh located in /etc/letsencrypt/renewal-hooks/deploy - #!/bin/sh systemctl restart nginx postfix dovecot echo "Certbot renewal\n\n$RENEWED_LINEAGE\n\n$RENEWED_DOMAINS" | mail -s "Certbot renewal" f...@bar.com - -- K Hi, trying to learn the mailing list conventions as Yassine pointed out to me it is customary to reply to the list. I am guessing the certbot version I use reloads apache config on renewal since I've never had this problem on port 80. Thanks for the renewal-hooks, I had found out that's where they live but wasn't sure if the $RENEWED_DOMAINS were available but from you answer I guess they are. As Patrick pointed out to me a reload is better since a config error won't stop the services. Thank you all for your kind answers. I've had a topic running on https://serverfault.com/questions/958093/dovecot-issued-expired-certificate/958104#958104 which I am going to update with my findings based on your help so that other people might benefit. Regards, MajorLabel
Re: flags not synced correctly with dovecot sync (dsync)
On 13 Mar 2019, at 22.43, Dan Christensen via dovecot wrote: > > On Mar 12, 2019, Dan Christensen via dovecot wrote: > >> In another thread, Timo wrote: >> >> On Mar 12, 2019, Timo Sirainen via dovecot wrote: >> >>> That bug is fixed with attached patch. >> >> I'll report back once I've tested it. > > I applied 2656.patch to version 2.3.5 as found at > > https://repo.dovecot.org/ce-2.3-latest/ubuntu/bionic/pool/main/2.3.5-1_ce/ > > and rebuilt the ubuntu package. I installed the resulting package on > all three machines. And still I can reproduce the bug involving unread > messages getting marked as read. Looks like you're also using Maildir, which has another bug of keywords not being copied correctly.
Re: Am I right to assume certificate renewal with the same filename requires a dovecot reload/restart
On 3/14/19 9:55 AM, Patrick Cernko via dovecot wrote: [...] the way we have configured exim, it neither needs reload or restart but reads the certificate file every time it has to use it. What happens if you goof off in the middle of an opeartion, temporarily putting a wrong file instead of the new certificate, and exim starts delivering the new broken certificate right away ? or breaks ? or clients can't connect anymore with TLS ? or don't connect at all if you don't allow non-TLS connexions ? Yassine.
Re: Am I right to assume certificate renewal with the same filename requires a dovecot reload/restart
On Thu, Mar 14, 2019, at 11:33 AM, Yassine Chaouche via dovecot wrote: > On 3/14/19 9:32 AM, Yassine Chaouche via dovecot wrote: > > The general answere here is try and see, as you could totally test it > > on your own. The certificate is read at startup and put in memory for > > the rest of the execution time. Dovecot won't monitor the file for > > changes on disk, as this would waste CPU cycles and make dovecot only > > slower for no reason. The process (or person) that changes the file is > > responsible to restart dovecot to reload the new certificate in memory. > > > > Yassine. > > I should mention that this is also true for Apache and postfix. > > Yassine. Certbot has a feature to run scripts when renewing / deploying certificates. https://certbot.eff.org/docs/using.html#renewing-certificates Certbot also looks for these scripts under /etc/letsencrypt/renewal-hooks/pre post deploy FWIW here is my script restart.sh located in /etc/letsencrypt/renewal-hooks/deploy - #!/bin/sh systemctl restart nginx postfix dovecot echo "Certbot renewal\n\n$RENEWED_LINEAGE\n\n$RENEWED_DOMAINS" | mail -s "Certbot renewal" f...@bar.com - -- K
Re: Am I right to assume certificate renewal with the same filename requires a dovecot reload/restart
Hi, On 14.03.19 09:33, Yassine Chaouche via dovecot wrote: On 3/14/19 9:32 AM, Yassine Chaouche via dovecot wrote: The general answere here is try and see, as you could totally test it on your own. The certificate is read at startup and put in memory for the rest of the execution time. Dovecot won't monitor the file for changes on disk, as this would waste CPU cycles and make dovecot only slower for no reason. The process (or person) that changes the file is responsible to restart dovecot to reload the new certificate in memory. Yassine. I should mention that this is also true for Apache and postfix. on our debian systems, apache reloads the certificate file with service apache2 reload I never had to use "restart" to get the new certificate online. The advantage of reload is obvious: in case of a config error the daemon stays running (with the old config) whereas with restart you get a service downtime until you fixed the error. I guess dovecot's reload mechanism (doveadm reload) also rereads the certificate file, but I did not test that yet. However I just realized that doveadm reload exists with exitcode 0 even if there is an config error. You can only see the error message in the logs. At least the service keeps running (with the old config). I cannot say anything about postfix as we use exim. At least the way we have configured exim, it neither needs reload or restart but reads the certificate file every time it has to use it. Best, -- Patrick Cernko +49 681 9325 5815 Joint Administration: Information Services and Technology Max-Planck-Institute fuer Informatik & Softwaresysteme smime.p7s Description: S/MIME Cryptographic Signature
Re: Unable to set quota-fs plugin
On 3/13/19 2:10 PM, Eric Grammatico via dovecot wrote: Thanks Aki, Please find attached strace for imap and quota-status which report an error at the end. Regards, write(2, "/usr/libexec/dovecot/quota-statu"..., 57/usr/libexec/dovecot/quota-status: invalid option -- 'u' Please retry with the good options (-u is invalid) Yassine.
Re: Am I right to assume certificate renewal with the same filename requires a dovecot reload/restart
On 3/14/19 9:32 AM, Yassine Chaouche via dovecot wrote: The general answere here is try and see, as you could totally test it on your own. The certificate is read at startup and put in memory for the rest of the execution time. Dovecot won't monitor the file for changes on disk, as this would waste CPU cycles and make dovecot only slower for no reason. The process (or person) that changes the file is responsible to restart dovecot to reload the new certificate in memory. Yassine. I should mention that this is also true for Apache and postfix. Yassine.
Re: Am I right to assume certificate renewal with the same filename requires a dovecot reload/restart
The general answere here is try and see, as you could totally test it on your own. The certificate is read at startup and put in memory for the rest of the execution time. Dovecot won't monitor the file for changes on disk, as this would waste CPU cycles and make dovecot only slower for no reason. The process (or person) that changes the file is responsible to restart dovecot to reload the new certificate in memory. Yassine. On 3/14/19 9:14 AM, Guido Goluke, MajorLabel via dovecot wrote: Running dovecot 2.2, apologies if this question has been asked before: I've done the research but couldn't find anything. I run a server that uses dovecot as a MUA for Postfix and have a Let's Encrypt certificate that auto-renews through certbot on Ubuntu server 16.04. Dovecot did not pick up on the new certificate for the hostname. It did after a restart. To be clear: Let's Encrypt overwrites the previous certificate using the same path and filename. Am I right to assume that Dovecot needs a reload/restart after the certificate has been renewed in order to 'pick up' on the new certificate and if so, would I require a reload or a restart? Thank you in advance
Am I right to assume certificate renewal with the same filename requires a dovecot reload/restart
Running dovecot 2.2, apologies if this question has been asked before: I've done the research but couldn't find anything. I run a server that uses dovecot as a MUA for Postfix and have a Let's Encrypt certificate that auto-renews through certbot on Ubuntu server 16.04. Dovecot did not pick up on the new certificate for the hostname. It did after a restart. To be clear: Let's Encrypt overwrites the previous certificate using the same path and filename. Am I right to assume that Dovecot needs a reload/restart after the certificate has been renewed in order to 'pick up' on the new certificate and if so, would I require a reload or a restart? Thank you in advance -- MajorLabel
Dovecot logrotation - old journal files are still in use
Hi all Cannot understand, does it a bug or just a misconfiguration. In my Dovecot there are 3 files of logging (debug, info and .log)While executing logrotation, the new files are created, but old ones, namely dovecot.*.1 are still in use by the process I use next logrotate config for dovecot:/var/log/dovecot.log /var/log/dovecot.info /var/log/dovecot.debug { daily rotate 14 missingok notifempty compress delaycompress sharedscripts postrotate doveadm log reopen chmod 666 /var/log/dovecot.log chmod 666 /var/log/dovecot.info chmod 666 /var/log/dovecot.debug endscript}Here is the logger process in memory:root 19140 0.0 0.0 4140 1576 ? S Mar12 0:06 dovecot/log Here the files it uses after the daily logrotation:# lsof -p19140 |grep log...log 19140 root 33w REG 9,3 811 417675 /var/log/dovecot.log.1log 19140 root 34w REG 9,3 2842123 417681 /var/log/dovecot.info.1log 19140 root 35w REG 9,3 14853918 417683 /var/log/dovecot.debug.1...On manually issuing 'doveadm log reopen` used files are changed to# lsof -p19140 |grep dovecot\\\log 19140 root 33w REG 9,3 0 417651 /var/log/dovecot.loglog 19140 root 34w REG 9,3 121374 417690 /var/log/dovecot.infolog 19140 root 35w REG 9,3 916153 417691 /var/log/dovecot.debug as it is expected to beWhat can be the root of the issue? I use Dovecot as LDA for Postfix with system users, mbox mail format. System Slackware 12.0 x86, Postfix 2.4.5, Dovecot 2.2.36. Interconnect Postfix-Dovecot was made via mailbox_commandDovecot compiled from sources Logging configuration (file conf.d/10-logging.conf) contains the following:log_path = /var/log/dovecot.loginfo_log_path = /var/log/dovecot.infodebug_log_path = /var/log/dovecot.debugauth_verbose = yesauth_verbose_passwords = yesauth_debug = yesmail_debug = yesverbose_ssl = yesplugin {}Could the fact, that Postfix require Dovecot logs to be accessible someway, result in such a weird behavior? To allow other processes to access Dovecot logs I had to chmod 0666 all the current logs while integrating Dovecot into Postfix delivery (please see `chmod' commands in the logrotate config above) Thank youDenis Razoumovskiy
