Post-Auth external check?
Hello all, is it possible to include some post-auth check in the password authentication? So after dovecot has found a user allowed to login to execute some external script for checking additional conditions which gives back simple true or false wether the login should be allowed? -- Regards, Stephan ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: High availability of Dovecot
On Thu, 11 Apr 2019 16:44:40 +0800 luckydog xf via dovecot wrote: > Hi, list, > [...] >Thanks for any suggestions and ideas. > Hm, it seems most of the people answering have no real experience in production with suchs setups. Basically do this: - setup keepalived as a cluster director on both boxes for two VIP IPs where one is master for each and backup for the other. - configure keepalived to load-balance both servers on the services you want (e.g. SMTP, POP3, IMAP, POP3S, IMAPS, ...) - use a high persistence timeout so that the same client ends up mostly on the same service/box - you need several subnets to do this, so that your loadbalancing takes place on another subnet (not the external VIPs) - If either of the boxes fails, the other will take over the VIP and continue to serve the configured mail services, load-balancing will leave out the dead box This _will_ work in production, I promise, but you should be experienced with keepalived, arp, networking to do this setup. -- Regards, Stephan
Re: High availability of Dovecot
On Thu, 11 Apr 2019 16:44:40 +0800 luckydog xf via dovecot wrote: > Hi, list, > [...] >Thanks for any suggestions and ideas. > Hm, it seems most of the people answering have no real experience in production with suchs setups. Basically do this: - setup keepalived as a cluster director on both boxes for two VIPs where one is master for each and backup for the other. - configure keepalived to load-balance both servers on the services you want (e.g. SMTP, POP3, IMAP, POP3S, IMAPS, ...) - use a high persistence timeout so that the same client ends up mostly on the same service/box - you need several subnets to do this, so that your loadbalancing takes place on another subnet (not the external VIPs, neither the same subnet) - If either of the boxes fails, the other will take over the VIP and continue to serve the configured mail services, load-balancing will leave out the dead box This _will_ work in production, I promise, but you should be experienced with keepalived, arp, networking to do this setup. -- Regards, Stephan
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: 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: dovecot-lda without starting dovecot?
On Mon, 20 Nov 2017 12:05:46 +0200 Sami Ketola wrote: > > On 20 Nov 2017, at 10.50, Stephan von Krawczynski > > wrote: > > > > AFAIK no complex director stuff would be needed then, right? > > The second sentence implies that using file locking should also be enough, > > which dovecot does. > > You are building such a complex system and then you think that creating > director layer would be complex? > > Just out of curiosity may I ask what size of an environment is this? As it's > very hard for me to believe that this would scale. > > Sami If I had lets say 10 nodes handling incoming SMTP and delivery to local maildirs in parallel and independantly on a network storage and imapping this from another independant 4 nodes, then building a not needed bottleneck by shifting over the local delivery via director and LMTP to fewer nodes is just braindead creation of high loads on few boxes. And btw it scales perfectly because all that is needed if load increases is up'ing additional nodes for SMTP/delivery or IMAP _which are all the same (of two types)_. The loadbalancer needed for this can be equally used for e.g. web, ftp and other services. So there is absolutely no extra stuff needed for the mail setup. -- Regards, Stephan
Re: dovecot-lda without starting dovecot?
On Tue, 7 Nov 2017 21:40:55 +0200 Timo Sirainen wrote: > On 7 Nov 2017, at 21.33, Stephan von Krawczynski wrote: > > > > > > Me again have to stress that our former implementation of the lda process > > did do exactly nothing to all the dovecot files, and everything worked > > pretty well. We had no problems in years. So I really wonder if it > > wouldn't be the best way to simply cut away all the heavy dovecot magic > > from the lda as an option. All it really needs to do is pipe the mail into > > a temp file, do the sieve stuff and learn from it where to rename this > > temp file to, basically. On the other hand you have lots of config > > parameters in dovecot dealing with different approaches to lock files > > (from fcntl to dotlock). I would expect at least one of them to work over > > NFS. > > I suppose you could create a unique new per-delivery temporary directory > where dovecot-lda writes the mail, so it knows nothing about the user's real > home/mail directory. Then move it from there to Maildir/tmp/ -> rename to > Maildir/new/. I suppose you'd need to copy the Sieve script to the temp > directory. Not sure if something would have to be done > with .dovecot.lda-dupes. > > > And we do see stuff like: > > > > 2017-11-07T00:46:59.102961+01:00 mail-a05 dovecot: > > lda(someb...@somedomain.com): Warning: Locking transaction log > > file /dovecot.index.log took 40 seconds (appending) > > > > So some locking seems to work. > > The problem isn't locking, but caching of data. Especially because Dovecot > doesn't lock when reading files. The problem with data caching would not be existant if dovecot used O_DIRECT like proposed in the nfs (linux) docs. From nfs(5) manpage The NFS protocol is not designed to support true cluster file system cache coherence without some type of application serialization. If absolute cache coherence among clients is required, applications should use file locking. Alternatively, applications can also open their files with the O_DIRECT flag to disable data caching entirely. - end AFAIK no complex director stuff would be needed then, right? The second sentence implies that using file locking should also be enough, which dovecot does. -- Regards, Stephan
Re: Sieve global path?
On Fri, 10 Nov 2017 03:41:20 -0500 Bill Shirley wrote: > No it isn't shown as a folder. All folder directories here begin with a dot. > i.e. .INBOX .Trash .Drafts > > Bill No, they don't. me thought that, too. But using the rainloop webmail interface on top of such a config showed the sieve folder in the overview. Sometimes you can even see a "dovecot" folder, which also disappears when sieve is outside. -- Regards, Stephan > > On 11/10/2017 3:07 AM, Stephan von Krawczynski wrote: > > On Thu, 9 Nov 2017 21:02:44 -0500 > > Bill Shirley wrote: > > > >> Set the sieve_global_dir like this. > >> /etc/dovecot/conf.d/99-mystuff.conf: > >> . > >> . > >> plugin { > >> sieve = ~/Maildir/dovecot.sieve > >> sieve_dir = ~/Maildir/sieve > >> sieve_global_dir = /etc/dovecot/sieve/global/ > >> sieve_before = /etc/dovecot/sieve/before.d/ > >> # sieve_before2 = > >> # sieve_before3 = > >> sieve_after = /etc/dovecot/sieve/after.d/ > >> # sieve_after2 = > >> # sieve_after3 = > >> > >> fts = lucene > >> fts_lucene = whitespace_chars=@. > >> } > >> > >> Permissions: > >> drwxr-xr-x. 174 root root system_u:object_r:etc_t:s0 12288 Nov 9 > >> 11:43 /etc drwxr-xr-x. 4 root root system_u:object_r:dovecot_etc_t:s0 > >> 95 Apr 28 2016 /etc/dovecot drwxr-xr-x. 5 root root > >> system_u:object_r:dovecot_etc_t:s0 64 Jul 13 2015 /etc/dovecot/sieve > >> drwxr-xr-x. 2 root root system_u:object_r:dovecot_etc_t:s0 10 Jul 13 > >> 2015 /etc/dovecot/sieve/global > >> > >> Since this directory is read-only to all but root, pre-complie your > >> scripts with 'sievec'. > >> > >> Bill > > ... And don't follow this example setting sieve_dir inside your maildirs. > > This will lead to the dir being shown as imap folder which you don't want. > > Simply put out it outside and everything is fine. > >
Re: Sieve global path?
On Thu, 9 Nov 2017 21:02:44 -0500 Bill Shirley wrote: > Set the sieve_global_dir like this. > /etc/dovecot/conf.d/99-mystuff.conf: > . > . > plugin { > sieve = ~/Maildir/dovecot.sieve > sieve_dir = ~/Maildir/sieve > sieve_global_dir = /etc/dovecot/sieve/global/ > sieve_before = /etc/dovecot/sieve/before.d/ > # sieve_before2 = > # sieve_before3 = > sieve_after = /etc/dovecot/sieve/after.d/ > # sieve_after2 = > # sieve_after3 = > > fts = lucene > fts_lucene = whitespace_chars=@. > } > > Permissions: > drwxr-xr-x. 174 root root system_u:object_r:etc_t:s0 12288 Nov 9 > 11:43 /etc drwxr-xr-x. 4 root root system_u:object_r:dovecot_etc_t:s0 > 95 Apr 28 2016 /etc/dovecot drwxr-xr-x. 5 root root > system_u:object_r:dovecot_etc_t:s0 64 Jul 13 2015 /etc/dovecot/sieve > drwxr-xr-x. 2 root root system_u:object_r:dovecot_etc_t:s0 10 Jul 13 > 2015 /etc/dovecot/sieve/global > > Since this directory is read-only to all but root, pre-complie your scripts > with 'sievec'. > > Bill ... And don't follow this example setting sieve_dir inside your maildirs. This will lead to the dir being shown as imap folder which you don't want. Simply put out it outside and everything is fine. -- Regards, Stephan
Re: dovecot-lda without starting dovecot?
On Tue, 7 Nov 2017 19:19:23 +0200 Timo Sirainen wrote: > On 7 Nov 2017, at 9.15, Stephan von Krawczynski wrote: > > > > On Tue, 07 Nov 2017 13:19:12 +1000 > > Noel Butler wrote: > > > >> mail_location Optionally disable indexes using :INDEX=MEMORY > >> > >> don't use this on IMAP boxes, but is safe to use on SMTP and POP3's > >> boxes though > >> > >> eg: > >> > >> mail_location = > >> maildir:/var/vmail/%Ld/%1Ln/%1.1Ln/%2.1Ln/%Ln/Maildir:INDEX=MEMORY > >> > > Hello Noel, > > > > this sounds interesting. Can you please elaborate why you think this is no > > good idea for IMAP? > > We used a different LDA-scheme before (simply created the mail in > > maildir/tmp, then renamed it to maildir/new, just like Bernstein suggests > > to do) and it worked very well, no matter if the box was used whith IMAP > > or POP3. Why should there be any difference in using dovecot-lda without > > indexes? Does dovecot-lda "create" the new mail by atomic rename from tmp, > > too? > > Although the above disables updating indexes, there's still dovecot-uidlist > file that is always updated by dovecot-lda. It might also cause corruption > problems when multiple servers are accessing it at the same time. There's > some old code that attempts to avoid updating the uidlist when it's not > necessary (MAILBOX_TRANSACTION_FLAG_ASSIGN_UIDS==0), but I don't know if > that works. There's also .dovecot.lda-dupes file that is written. And the > Sieve scripts' compiled versions that you wanted to start using. In short: > This might work, but I have a feeling you'll run into random corruption > problems. I gave up trying to support simultaneous access in multiple > servers via NFS long time ago, because no matter what I did kernel always > cached too much and caused corruption (or alternatively it didn't cache > enough and caused performance problems). Hello Timo, Me again have to stress that our former implementation of the lda process did do exactly nothing to all the dovecot files, and everything worked pretty well. We had no problems in years. So I really wonder if it wouldn't be the best way to simply cut away all the heavy dovecot magic from the lda as an option. All it really needs to do is pipe the mail into a temp file, do the sieve stuff and learn from it where to rename this temp file to, basically. On the other hand you have lots of config parameters in dovecot dealing with different approaches to lock files (from fcntl to dotlock). I would expect at least one of them to work over NFS. And we do see stuff like: 2017-11-07T00:46:59.102961+01:00 mail-a05 dovecot: lda(someb...@somedomain.com): Warning: Locking transaction log file /dovecot.index.log took 40 seconds (appending) So some locking seems to work. -- Regards, Stephan
Re: dovecot-lda without starting dovecot?
On Tue, 07 Nov 2017 13:19:12 +1000 Noel Butler wrote: > mail_location Optionally disable indexes using :INDEX=MEMORY > > don't use this on IMAP boxes, but is safe to use on SMTP and POP3's > boxes though > > eg: > > mail_location = > maildir:/var/vmail/%Ld/%1Ln/%1.1Ln/%2.1Ln/%Ln/Maildir:INDEX=MEMORY > > -- > Kind Regards, > > Noel Butler Hello Noel, this sounds interesting. Can you please elaborate why you think this is no good idea for IMAP? We used a different LDA-scheme before (simply created the mail in maildir/tmp, then renamed it to maildir/new, just like Bernstein suggests to do) and it worked very well, no matter if the box was used whith IMAP or POP3. Why should there be any difference in using dovecot-lda without indexes? Does dovecot-lda "create" the new mail by atomic rename from tmp, too? -- Regards, Stephan
Re: dovecot-lda without starting dovecot?
On Mon, 6 Nov 2017 09:50:16 -0500 Tanstaafl wrote: > On 11/6/2017, 4:01:19 AM, Stephan von Krawczynski > wrote: > > Still we are not content with it touching/locking dovecot.index.log. If > > someone pointed at one location in the code where this could be disabled we > > would implement a new param for switching that off. > > ? > > Dovecot's indexing is one of its main features, and WHY it is so much > faster than others. > > And you want to just turn it off? Good luck... It seems you have not understood what I am talking about. Our pre-dovecot lda did not touch the index either. And it did not harm the imap/pop procedure in any way. So we know there is no need to fiddle with the index in the process of delivery into the maildirs to keep our performance as it was before. -- Regards, Stephan
Re: dovecot-lda without starting dovecot?
On Mon, 6 Nov 2017 08:37:11 +0200 Sami Ketola wrote: > > On 5 Nov 2017, at 12.55, Stephan von Krawczynski > > wrote: Sorry to say this setup works flawlessly for years. The only > > addition we will make now is to do the delivery with dovecot-lda. > > Everything else (including multiple dovecot pop/imap servers) will stay as > > is. Hopefully dovecot-lda does not fiddle around with the indexes too > > much, as we then would have to delete this part of the code out. It is not > > needed as we found out during the last 10 years of delivering mails into > > the maildirs by atomic rename action while dovecot is presenting them over > > imap. > > > Feel free to do anything you like. I'm just going to mention to people later > reading these from the achives not to take this kind of strange hack as an > example of recommended dovecot clustering. Instead consider it as an > opposite of any best practices cluster setup. > > Sami Maybe they are interested that it runs like charm ;-) Of course it is overly complex to let dovecot-lda look up the mail_location since we already know that when starting it, but at least it shows a nice output in the logs. Still we are not content with it touching/locking dovecot.index.log. If someone pointed at one location in the code where this could be disabled we would implement a new param for switching that off. -- Regards, Stephan
Re: dovecot-lda without starting dovecot?
On Sun, 5 Nov 2017 10:44:25 +0200 Sami Ketola wrote: > > On 4 Nov 2017, at 10.31, Stephan von Krawczynski > > wrote: > > > > On Sat, 4 Nov 2017 01:57:31 +0200 > > Sami Ketola wrote: > >> Again that does not answer my question why? Why do you want all the > >> locking problems and multi-access problems that come with setup like > >> that? What is the actual problem that you are trying to solve? > >> > >> Sami > > > > Really, I can hardly believe you don't now large loadbalancing ISP setups > > with multiple nodes per single service ...? > > The simple problem: massive numbers of emails > > Nope. Has never been done. Has never been recommended way. You will get more > problems with that setup that you are seeking to solve. > > Use multiple dovecot backends with director ring in front and switch to lmtp > delivery via the director ring if you have scalability problems. Then you > can just increase number of backends in case they are overloaded. > > Sami Sorry to say this setup works flawlessly for years. The only addition we will make now is to do the delivery with dovecot-lda. Everything else (including multiple dovecot pop/imap servers) will stay as is. Hopefully dovecot-lda does not fiddle around with the indexes too much, as we then would have to delete this part of the code out. It is not needed as we found out during the last 10 years of delivering mails into the maildirs by atomic rename action while dovecot is presenting them over imap. -- Regards, Stephan
Re: dovecot-lda without starting dovecot?
On Sat, 4 Nov 2017 01:57:31 +0200 Sami Ketola wrote: > >> > >> While it might be possible to disable all the other services except > >> master I must ask why? How would the users be accessing their mails then? > >> > >> Sami > > > > Hello Sami, > > > > you did not read my first post. We are talking about a multihost > > installation where one host does SMTP and LDA, and the other does POP and > > IMAP (with dovecot). Now we want to use dovecot-lda for the local delivery > > _on the SMTP host_. So there is no need for open POP or IMAP ports and the > > corresponding running services. > > Again that does not answer my question why? Why do you want all the locking > problems and multi-access problems that come with setup like that? What is > the actual problem that you are trying to solve? > > Sami Really, I can hardly believe you don't now large loadbalancing ISP setups with multiple nodes per single service ...? The simple problem: massive numbers of emails -- Regards, Stephan
Re: dovecot-lda without starting dovecot?
On Fri, 3 Nov 2017 19:30:22 +0200 Sami Ketola wrote: > > On 3 Nov 2017, at 18.23, Stephan von Krawczynski > > wrote: Hello Aki, > > > > let me explain this a bit more. We do not intend to use only some copied > > binary. Of course we would do a full installation of dovecot and > > pidgeonhole, only we question if it is necessary to start the dovecot > > init-file bringing up the dovecot imap/imap-login/pop/pop-login/auth and > > other processes. Indeed we have virtual users. > > > While it might be possible to disable all the other services except master I > must ask why? How would the users be accessing their mails then? > > Sami Hello Sami, you did not read my first post. We are talking about a multihost installation where one host does SMTP and LDA, and the other does POP and IMAP (with dovecot). Now we want to use dovecot-lda for the local delivery _on the SMTP host_. So there is no need for open POP or IMAP ports and the corresponding running services. -- Regards, Stephan
Re: dovecot-lda without starting dovecot?
On Fri, 3 Nov 2017 17:53:47 +0200 (EET) Aki Tuomi wrote: > > On November 3, 2017 at 1:50 PM Stephan von Krawczynski > > wrote: > > > > > > Hello, > > > > we have a setup where SMTP/LDA and POP3/IMAP are on different physical > > hosts. They share the mail data via an external storage. > > Now we would like to use dovecot-lda on the smtp host, so we wonder if the > > lda binary works without starting dovecot from init. As there will be no > > POP3/IMAP usage on this host it seems unnecessary. Nevertheless we cannot > > judge if it is still needed for lda&sieve to work. > > Your opinion? > > > > -- > > Regards, > > Stephan > > dovecot-lda does not work without dovecot unless you have physical users and > you run the binary as target user. with virtual users it's virtually > impossible to achieve. > > Aki Hello Aki, let me explain this a bit more. We do not intend to use only some copied binary. Of course we would do a full installation of dovecot and pidgeonhole, only we question if it is necessary to start the dovecot init-file bringing up the dovecot imap/imap-login/pop/pop-login/auth and other processes. Indeed we have virtual users. -- Regards, Stephan
dovecot-lda without starting dovecot?
Hello, we have a setup where SMTP/LDA and POP3/IMAP are on different physical hosts. They share the mail data via an external storage. Now we would like to use dovecot-lda on the smtp host, so we wonder if the lda binary works without starting dovecot from init. As there will be no POP3/IMAP usage on this host it seems unnecessary. Nevertheless we cannot judge if it is still needed for lda&sieve to work. Your opinion? -- Regards, Stephan
Re: is a self signed certificate always invalid the first time
On Sun, 20 Aug 2017 12:29:49 -0400 KT Walrus wrote: > > On Aug 20, 2017, at 11:52 AM, Stephan von Krawczynski > > wrote: > > > > On Sat, 19 Aug 2017 21:39:18 -0400 > > KT Walrus wrote: > > > >>> On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski > >>> wrote: > >>> > >>> On Fri, 18 Aug 2017 00:24:39 -0700 (PDT) > >>> Joseph Tam wrote: > >>> > >>>> Michael Felt writes: > >>>> > >>>>>> I use acme.sh for all of my LetsEncrypt certs (web & mail), it is > >>>>>> written in pure shell script, so no python dependencies. > >>>>>> https://github.com/Neilpang/acme.sh > >>>>> > >>>>> Thanks - I might look at that, but as Ralph mentions in his reply - > >>>>> Let's encrypt certs are only for three months - never ending > >>>>> circus. > >>>> > >>>> I wouldn't characterize it as a circus. Once you bootstrap your first > >>>> certificate and install the cert-renew cron script, it's not something > >>>> you have to pay a lot of attention to. I have a few LE certs in use, > >>>> and I don't think about it anymore: it just works. > >>>> > >>>> The shorter cert lifetime also helps limit damage if your certificate > >>>> gets compromised. > >>>> > >>>> Joseph Tam > >>> > >>> Obviously you do not use clustered environments with more than one node > >>> per service. > >>> Else you would not call it "it just works", because in fact the renewal > >>> is quite big bs as one node must do the job while all the others must be > >>> _offline_. > >>> > >>> -- > >>> Regards, > >>> Stephan > >> > >> I use DNS verification for LE certs. Much better since generating certs > >> only depends on access to DNS and not your HTTP servers. Cert generation > >> is automatic (on a cron job that runs every night looking for certs that > >> are within 30 days of expiration). Once set up, it is pretty much > >> automatic. I do use Docker to deploy all services for my website which > >> also makes things pretty easy to manage. > >> > >> Kevin > >> > > > > DNS verification sounds nice only on first glimpse. > > If you have a lot of domains and ought to reload your DNS for every > > verification of every single domain that does not look like a method with a > > small footprint or particularly elegant. > > I don’t understand what you are trying to say. I have over 170 domains that > I generate certs for automatically using the acme.sh script. It is all > automatic and requires no “reload your DNS” by me. The script just updates > the DNS with a record that Let’s Encrypt checks before issuing the > certificate. After Let’s Encrypt verifies that you can update the DNS for > your domain with the record, the script removes the record. > > This actually works much better than HTTP especially for domains like for > email servers that don’t have an HTTP server deployed for them. > > Kevin You can't update a record without reloading configs in bind. I guess you are using some other DNS service... -- Regards, Stephan
Re: is a self signed certificate always invalid the first time
On Sat, 19 Aug 2017 21:39:18 -0400 KT Walrus wrote: > > On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski > > wrote: > > > > On Fri, 18 Aug 2017 00:24:39 -0700 (PDT) > > Joseph Tam wrote: > > > >> Michael Felt writes: > >> > >>>> I use acme.sh for all of my LetsEncrypt certs (web & mail), it is > >>>> written in pure shell script, so no python dependencies. > >>>> https://github.com/Neilpang/acme.sh > >>> > >>> Thanks - I might look at that, but as Ralph mentions in his reply - > >>> Let's encrypt certs are only for three months - never ending circus. > >> > >> I wouldn't characterize it as a circus. Once you bootstrap your first > >> certificate and install the cert-renew cron script, it's not something > >> you have to pay a lot of attention to. I have a few LE certs in use, > >> and I don't think about it anymore: it just works. > >> > >> The shorter cert lifetime also helps limit damage if your certificate > >> gets compromised. > >> > >> Joseph Tam > > > > Obviously you do not use clustered environments with more than one node per > > service. > > Else you would not call it "it just works", because in fact the renewal is > > quite big bs as one node must do the job while all the others must be > > _offline_. > > > > -- > > Regards, > > Stephan > > I use DNS verification for LE certs. Much better since generating certs only > depends on access to DNS and not your HTTP servers. Cert generation is > automatic (on a cron job that runs every night looking for certs that are > within 30 days of expiration). Once set up, it is pretty much automatic. I > do use Docker to deploy all services for my website which also makes things > pretty easy to manage. > > Kevin > DNS verification sounds nice only on first glimpse. If you have a lot of domains and ought to reload your DNS for every verification of every single domain that does not look like a method with a small footprint or particularly elegant. -- Regards, Stephan
Re: is a self signed certificate always invalid the first time
On Fri, 18 Aug 2017 00:24:39 -0700 (PDT) Joseph Tam wrote: > Michael Felt writes: > > >> I use acme.sh for all of my LetsEncrypt certs (web & mail), it is > >> written in pure shell script, so no python dependencies. > >> https://github.com/Neilpang/acme.sh > > > > Thanks - I might look at that, but as Ralph mentions in his reply - > > Let's encrypt certs are only for three months - never ending circus. > > I wouldn't characterize it as a circus. Once you bootstrap your first > certificate and install the cert-renew cron script, it's not something > you have to pay a lot of attention to. I have a few LE certs in use, > and I don't think about it anymore: it just works. > > The shorter cert lifetime also helps limit damage if your certificate > gets compromised. > > Joseph Tam Obviously you do not use clustered environments with more than one node per service. Else you would not call it "it just works", because in fact the renewal is quite big bs as one node must do the job while all the others must be _offline_. -- Regards, Stephan
Re: is a self signed certificate always invalid the first time?
On Thu, 10 Aug 2017 07:53:16 -0700 Gregory Sloop wrote: > [...] > Clearly there *are* issues with trusted CA's. But they also offer some value > you can't get with a self-signed cert - especially to people who would > connect to your servers, but who have no real relationship with you and thus > no reason to have any trust for you or your certificates. [...] Cheers! -Greg Let me drop all the rest and concentrate on this idea of yours. You really do mean that someone not trusting the issuer of some web site is _protected_ iff this very web uses a certificate from a trusted CA? How should that work out? If someone does not trust me or my certificate he should not use my web at all. The signed-by-CA certificate will not improve the content of the web (or other service) and therefore would be a fake security component anyway if I'd like to harm the visitor somehow. What kind of an argument is this? Really, the quality of the protected service is not linked in any way to the used certificate. -- Regards, Stephan
Re: is a self signed certificate always invalid the first time?
On Wed, 9 Aug 2017 08:39:30 -0700 Gregory Sloop wrote: > AV> So i’m using dovecot, and i created a self signed certificate > AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches > AV> my mail server. > > AV> The first time it connects in mac mail however, it says the > AV> certificate is invalid and another server might pretend to be me etc. > > AV> I then have the option of trusting it. > > AV> Is this normal behaviour? Will it always be invalid if it’s not signed > AV> by a third party? > > Yes. > The point of a trusted CA signing your cert is that they have steps to > "verify" who you are and that you're "authorized" to issue certs for the > listed FQDNs. Without that, ANYONE could create a cert, and sign it and then > present it to people connecting to your mail server [perhaps using a MITM > style attack.] The connecting party would have no way to tell if your cert > vs the attackers cert was actually valid. > > It would be like showing up at the bank and having this exchange: > > You: "Hey, I'm Jim Bob - can I take money out of his account?" > Bank: "Do you have some ID?" > You: "Yeah! See, I have this plastic card with my picture and name, that I > ginned up in the basement." > > Now does the bank say: "Yeah, that looks fine." or do they say "You know we > really need ID [a certificate] that's authenticated and issued [signed] by > the state [third-party/trusted CA.]." > > I think it's obvious that accepting your basement produced ID would be a > problem. [Even if we also admit that while the state issued ID (or trusted > CA signed certs) has some additional value, it isn't without potential > flaws, etc.] > > The alternative would be to add your CA cert [the one you signed the server > cert with] to all the connecting clients as a trusted CA. This way your self > signed cert would now be "trusted." > > [The details are left as an exercise to the reader. Google is your friend.] > > -Greg This was exactly the global thinking - until the day DigiNotar fell. Since that day everybody should be aware that the true problem of a certificate is not its issuer, but the "trusted" third party CA. This could have been known way before of course by simply thinking about the basics. Do you really think your certificate gets more trustworthy because some guys from South Africa (just an example) say it is correct, running a _business_? Honestly, that is just naive. It would be far better to use a self-signed certificate that can be checked through some instance/host set inside your domain. Because only then the only one being responsible and trustworthy is yourself. And that is the way it should be. Everything else involving third party business is just bogus. -- Regards, Stephan
Re: Email hosting provider
On Sat, 26 Mar 2016 13:34:34 +1000 Noel Butler wrote: > On 21/03/2016 17:06, Andre Rodier wrote: > > Hello, > > > > Sorry if I am off topic a little. > > > > I am looking for an email host provider that supports dovecot, sieve > > and manage sieve. Ideally with the roundcube webmail and managesieve > > plugin > > > > Better if it is in Europe or switzerland. I don't mind paying a little. > > > > Thanks, > > André. > > Hi Andre, > > see www.webhostingtalk.com > > There are a number of reliable and reasonable priced hosts in Germany > (best place if you value your privacy) and Netherlands. You mean "best place if you have no idea of the german laws and whats really going on" ... -- Regards, Stephan
Re: NetApp NFS vs. ZFS and NFS for Maildir
On Sat, 19 Mar 2016 17:37:04 +1000 Noel Butler wrote: > On 14/03/2016 18:49, Stephan von Krawczynski wrote: > > > >> > >> and you've never seen these cause problems with FS? then you must be > >> a > >> newbie, in over 25 years I've seen it happen several times - yes even > >> after an apparent controlled shutdown. > > > > Maybe you're doing something wrong then. because in my last 21 years > > working > > exactly in this business I've not seen a single deadly fs-crash because > > of a > > power-outage. Not one. And we had of course several, all backed by UPS. > > Consider yourself lucky, Most network admins whove been around large > busy ISP DC's have seen this in their lifetime, to not have seen one is > rare, go buy yourself a lotto ticket :) > > > > > If your servers get drowned with water during a fire your fs is > > probably the > > least of your worries. You don't really plan to re-enable servers with > > water- or fire-damage, do you? That's probably why there shouldn't be a > > fireman pouring water in the first place. > > This shows you dont understand structural engineering, the fire does not > have to be on your floor, it can be far away as two or so levels above, > with the high pressure water used - equating to a shitload of water, > there are ducts, shafts, other risers and so on that with a shit-tone of > water can easily penetrate fireblocks of floors below - dont take my > work, go ask a fireman, or maybe watch the nightly news sometime > (building fire - many levels water affected blah blah blah)... so > keeping those boxes on via UPS's is asking for lots of charcoaled boards > and fried drives. IOW, total stupidity. > > Should those machines be depowered as required by our building codes, > well, might take a few days of drying out but at least they will power > back up without error - yes, done it in risk assessments. Obviously you must work for people that have not the slightest idea about using hardware in a correct way and don't know when the time has come to throw it away. Man, there is no way to let a drowned box survive. It is not back to normal when it is dry. If you don't get that I am pretty happy to be no customer. This can only be an idea born in the sick mind of a controller who didn't want to pay insurance in the first place. We are talking about serious corrosion effects here let alone that you have a hard time even knowning when your boxes are really dry. Your fireman on the other hand seem to be stuck in the 80ths. Today there are solar panels almost everywhere _which you cannot turn off_. Sure you have a switch somewhere, but it does not help you for the space between the switch and the roof (which can be a pretty long distance). Really, sorry, I don't want to listen to more horror stories from you operating drowned equipment. And in the end: considering your "large busy ISP DC's" they should have backup DCs located elsewhere with mirrored data, right? Lets please end that now and for all. -- Regards, Stephan
Re: NetApp NFS vs. ZFS and NFS for Maildir
On Mon, 14 Mar 2016 16:59:28 +1000 Noel Butler wrote: > On 14/03/2016 09:59, Stephan von Krawczynski wrote: > > On Mon, 14 Mar 2016 09:32:42 +1000 > > Noel Butler wrote: > > > >> On 13/03/2016 20:47, Stephan von Krawczynski wrote: > >> > On Sun, 13 Mar 2016 09:45:06 + > >> > James wrote: > >> > > >> >> On 11/03/2016 15:17, Stephan von Krawczynski wrote: > >> >> > >> >> > zfs set sync=disabled ? > >> >> > >> >> Only if you are happy to loose data on power failure. > >> > > >> > I don't know the actual setup, but if you have no UPC you shouldn't > >> > host email > >> > services anyway. > >> > >> I'm guessing you meant UPS, anyway, a UPS wont protect you from human > >> error. > >> > >> Also, most buildings, at least in this country, have a fire emergency > >> shutoff requirement, meaning mains is isolated from the building, and > >> the back up gennies are also forbidden to be engaged - UPS's dont last > >> forever. > > > > Guys, please don't argue on kindergarten level. The UPS is for backing > > a > > sudden death, but not for running five days. Of course you can do a > > controlled > > shutdown if battery level falls below a trigger value. And this is > > about all > > you need: control. There is no fs error as long as you perform a > > regular > > and you've never seen these cause problems with FS? then you must be a > newbie, in over 25 years I've seen it happen several times - yes even > after an apparent controlled shutdown. Maybe you're doing something wrong then. because in my last 21 years working exactly in this business I've not seen a single deadly fs-crash because of a power-outage. Not one. And we had of course several, all backed by UPS. > > shutdown. If UPS-backup is forbidden in your country then I suggest > > moving to > > civilized regions of the planet ;-) > > Now whos on kindergarten level, do you really want fireman pouring water > on fire on a level of a building thats powered up because some lamer has > a generator running? really? I'm sure those firemen would gladly hand > YOU the hose, the best UPS systems runtime we've seen under average load > for a large ISP data centre is 21 mins, usually ample time to allow the > generators to start up, come to full power, and switch in taking over > the load, but thats not going to help during a building fire, once their > depleted, their depleted. If your servers get drowned with water during a fire your fs is probably the least of your worries. You don't really plan to re-enable servers with water- or fire-damage, do you? That's probably why there shouldn't be a fireman pouring water in the first place. Please lets stop this here as it has pretty much nothing to do with dovecot... -- Regards, Stephan
Re: NetApp NFS vs. ZFS and NFS for Maildir
On Mon, 14 Mar 2016 09:32:42 +1000 Noel Butler wrote: > On 13/03/2016 20:47, Stephan von Krawczynski wrote: > > On Sun, 13 Mar 2016 09:45:06 + > > James wrote: > > > >> On 11/03/2016 15:17, Stephan von Krawczynski wrote: > >> > >> > zfs set sync=disabled ? > >> > >> Only if you are happy to loose data on power failure. > > > > I don't know the actual setup, but if you have no UPC you shouldn't > > host email > > services anyway. > > I'm guessing you meant UPS, anyway, a UPS wont protect you from human > error. > > Also, most buildings, at least in this country, have a fire emergency > shutoff requirement, meaning mains is isolated from the building, and > the back up gennies are also forbidden to be engaged - UPS's dont last > forever. Guys, please don't argue on kindergarten level. The UPS is for backing a sudden death, but not for running five days. Of course you can do a controlled shutdown if battery level falls below a trigger value. And this is about all you need: control. There is no fs error as long as you perform a regular shutdown. If UPS-backup is forbidden in your country then I suggest moving to civilized regions of the planet ;-) -- Regards, Stephan
Re: NetApp NFS vs. ZFS and NFS for Maildir
On Sun, 13 Mar 2016 11:47:23 +0100 Stephan von Krawczynski wrote: > On Sun, 13 Mar 2016 09:45:06 + > James wrote: > > > On 11/03/2016 15:17, Stephan von Krawczynski wrote: > > > > > zfs set sync=disabled ? > > > > Only if you are happy to loose data on power failure. > > I don't know the actual setup, but if you have no UPC you shouldn't host email > services anyway. That should read "UPS" of course ... > -- > Regards, > Stephan
Re: NetApp NFS vs. ZFS and NFS for Maildir
On Sun, 13 Mar 2016 09:45:06 + James wrote: > On 11/03/2016 15:17, Stephan von Krawczynski wrote: > > > zfs set sync=disabled ? > > Only if you are happy to loose data on power failure. I don't know the actual setup, but if you have no UPC you shouldn't host email services anyway. -- Regards, Stephan
Re: NetApp NFS vs. ZFS and NFS for Maildir
On Fri, 11 Mar 2016 11:58:00 -0300 Juan Bernhard wrote: > > El 11/03/2016 a las 11:22 a.m., Alessio Cecchi escribió: > > Hi, > > > > I'm evaluating to switch from NetApp to a ZFS appliance (like Qsan). Our > > setup is Dovecot, Maildir for email storage and NFS to share mailboxes > > (more than 30k users) across POP/IMAP and MX servers. > > > > NetApp NFS works fine also under high load but have some limitation for > > inode numbers per Volume and is expensive (but recently their prices > > have dropped). > > > > ZFS, I read, suggest to create many small Raid Group to increase IOPS, > > but this configuration (N Raid instead of one RAID-DP like NetApp) is > > more complex to manage, or not? > > > > Someone has experiences with ZFS and NFS(v3) in high load environments? > > > > Thanks > > Be careful to no do any synchronous writes under ZFS. Every sync write > can take up to 3 seconds of latency (under freebsd, I didnt test ZFS in > linux). Im using it in a 3k user environment and works great with a 4TB > raid 10, and dovecot cache files in a SSD disk. > > Saludos, Juan. zfs set sync=disabled ? -- Regards, Stephan
Re: AW: ot: accepting self certs into win pc?
On Tue, 24 Jun 2014 17:03:09 +0200 Patrick De Zordo wrote: > Don't use self signed certs! - Buy some, or use free services! Your > reputation will grow! I am sorry, but someone _has_ to say it: if anyone really thinks that a south african or US entity selling certs is the way to "grow your reputation" this alone should tell you that the whole thing is nothing but a bogus _business_. It has zero to do with security or the like. It is a _business_ and it should be obvious that you will only be lied by the corresponding entity if something bad happened (probably for years). Look at the diginotar story and _learn_. The only way to make certs worth using again is to create a way every client can verify a self-signed certificate by some kind of dns pointer inside the questionable domain and/or the certificate. You cannot prove the correctness of a third party entity, and that's why there is no reputation at all. > Cheers! Yes, have a beer... -- Regards, Stephan
Re: [Dovecot] How to bring dovecot to using a slightly modified passwd file
On Mon, 21 Apr 2014 17:26:13 +0200 Andreas Schulze wrote: > Stephan von Krawczynski: > > If there is no chance to convince Timo for something like a passwd-scheme > > parameter useful for more people than just me I will probably rewrite the > > stuff myself. Nevertheless if someone kindly points me to the right piece of > > code I could save some hours searching for it myself... > Stephan, > > I'm not aware on any function you need to specify the passwd layout. > So a short solution would be a patch to dovecot. > > A more general solution could be a separate scheme beside > the existing auth backends http://wiki2.dovecot.org/PasswordDatabase > or a mechanism to specify passwd fields as you suggested. > > Andreas Hello Andreas, I am well aware of the several possibilities around passwd and userdb. The thing is I want to avoid using scripts or an external binary (which would be possible) for performance reasons. I think the internal passwd file handling from dovecot would be best. It should be pretty easy to do a patched version where only the fields are replaced by the ones my passwd files use. -- Regards, Stephan
Re: [Dovecot] How to bring dovecot to using a slightly modified passwd file
On Mon, 21 Apr 2014 13:38:59 +0200 Benny Pedersen wrote: > Stephan von Krawczynski skrev den 2014-04-21 09:33: > > > Or do I have to patch the source, and where if necessary? > > dovecot does not need passwd files, you can eg use any db that dovecot > support, lets say sqlite, then you can make layout free of charge > > make a php wrapper that import flat filedb to sqlite, and another one to > export sqlite to fliledb > > that would be heaven imho :) > > and at the same time a nice backup Hello Benny, there are good reasons why this is _not_ possible. The setup is complex and lots of other software parts depend on the passwd file. Since they should all be interacting it is no good idea to spread the same data over several "databases". Furthermore we are not talking about _one_ passwd-like file but thousands (one for every domain). Believe me, I thought about it before asking exactly this question and not for some solution. If there is no chance to convince Timo for something like a passwd-scheme parameter useful for more people than just me I will probably rewrite the stuff myself. Nevertheless if someone kindly points me to the right piece of code I could save some hours searching for it myself... -- Regards, Stephan
[Dovecot] How to bring dovecot to using a slightly modified passwd file
Hello all, I am trying to use a setup where domains have separate passwd files with a slightly different layout. Is there a way to tell dovecot that a passwd file contains everything it looks for but on different positions inside the passwd file line? Standard passwd: USERNAME:PASSWD:UID:GID:HOME:extras different layout: USERNAME:PASSWD:extras:UID:GID:HOME Or do I have to patch the source, and where if necessary? Thanks for your help. -- Regards, Stephan
Re: [Dovecot] Changing SSL certificates - switching from self-signed to RapidSSL
On Sat, 19 Apr 2014 10:20:39 +0200 Reindl Harald wrote: > and where does it lead to trigger warnings all over the planet and train > people to ignore them? in case of a mailserver that's not a real big > problem because they amount of users is limited > > on a public website it is insane to present a browser warning as welcome > message > > if there is a working replacement, widely supported by client-software > and useable or the ordinary enduser - fine - let us adopt it - until > that does not exist you are talking bullshit > > well, i have an offer for you: > you pay the support calls caused by certificate warnings, you pay also the > harm of other ignored warnings as result of train monkeys, you go out and > make *every* enduser to a tech person understand certificates and SSL before > and after that we all start to drop CA certificates > > deal? So you like market behaviour. Don't you think that the market of client software will react faster if everybody is aware of the currently unsolved problems? My word is: make them aware. Your word is: safe money and give a damn. Lets stop it here, it is obvious we disagree and I guess people on the list have heard enough to take their own decisions. -- Regards, Stephan
Re: [Dovecot] Changing SSL certificates - switching from self-signed to RapidSSL
On Sat, 19 Apr 2014 09:40:07 +0200 Reindl Harald wrote: > it is working, it is working as good as it can and if you compare the > costs of 130 € for 3 years with support calls because self signed > certificates and do a *real harm* by train ordinary users to ignore > warnings just guess which way works > > honestly if i connect to a server owned by a company coming > with a self-signed certificate without got told so before > i get alarmed that they may not be trustworthy because if they > save the little money for the cert i may assume they save money > on other important things too Honestly, with your awareness of "as good as it can" wouldn't it be fair to tell people that they spend millions all over the planet for something that is not working? How can you expect the situation to get any better if you cover the problem by buying certs only for the reason to avoid warnings that are useless anyways? You know things go wrong and still do support it. I think one should have learned in the after-Snowden-era where this leads to. -- Regards, Stephan
Re: [Dovecot] Changing SSL certificates - switching from self-signed to RapidSSL
On Sat, 19 Apr 2014 09:22:07 +0200 Reindl Harald wrote: > > > Am 19.04.2014 09:14, schrieb Stephan von Krawczynski: > > On Fri, 18 Apr 2014 13:57:47 -0400 > > Charles Marcus wrote: > > > >> Hi all, > >> > >> Ok, been wanting to do this for a while, and I after the Heartbleed > >> fiasco, the boss finally agreed to let me buy some real certs... > > > > Well, I guess one has to tell you that: > > 1) No certs no matter if self-signed or not would have saved you from > > heartbleed > > yes, but you seem not to understand hat "Heartbleed" is the moment > which you can use to say "now let us take SSL serious" in general > as well as other security topics because *now* you can point > somewehere and say "look manager, things happening in real" Yes, but all he has to do is ask you if this problem would have arised if he had a "real cert" to know that your spending money would not have helped. > > 2) "real certs" issued from cert-dealers are no more safe than your > > self-signed was. In fact they add the risk of your cert-dealter being hacked > > and you don't know. _This has happened_ already for at least one > > cert-dealer. > > So there is no proof at all that it will not happen again and this time > > probably nobody will be informed, because the company is dead afterwards > > (just > > like diginotar). In fact the whole cert business is a big fake currently > > yes but you can't change that nor can i So you say: "better fake security than no security" ? > > 3) The whole SSL stuff can only be made secure by implementing methods to > > authorize self-signed certs yourself and the clients using it being able to > > check that. Every checking by external "authorities" is just an > > uncontrollable > > security hole. > > bulls**t because you can't do that if your mailusers are ordianary > customers and even if you get managed that they import your self > signed cert that *does not* change the fact that they get no alert > in case of a MITM attack presenting whatever certificate signed > from a CA all clients are trusting > > without certificate pinning you are lost in any case and with > certificate pinning you can avoid the inital warning nobody > of the ordinary users understands - so until you come with > a solution for certificate pinning on and endusers MUA better > don't explain things anybody knows It does not matter if you can do something _now_ or not. The only way to improve a not working situation is to tell that it is not working (my way) and not to ignore it (your way). -- Regards, Stephan
Re: [Dovecot] Changing SSL certificates - switching from self-signed to RapidSSL
On Fri, 18 Apr 2014 13:57:47 -0400 Charles Marcus wrote: > Hi all, > > Ok, been wanting to do this for a while, and I after the Heartbleed > fiasco, the boss finally agreed to let me buy some real certs... Well, I guess one has to tell you that: 1) No certs no matter if self-signed or not would have saved you from heartbleed. 2) "real certs" issued from cert-dealers are no more safe than your self-signed was. In fact they add the risk of your cert-dealter being hacked and you don't know. _This has happened_ already for at least one cert-dealer. So there is no proof at all that it will not happen again and this time probably nobody will be informed, because the company is dead afterwards (just like diginotar). In fact the whole cert business is a big fake currently. 3) The whole SSL stuff can only be made secure by implementing methods to authorize self-signed certs yourself and the clients using it being able to check that. Every checking by external "authorities" is just an uncontrollable security hole. -- Regards, Stephan
Re: [Dovecot] OT/about SSDs
Honestly guys, most people really have no long-term experiences with flash memory, be it SSD or other forms of. I can tell you from continously using simple CF-Cards as harddisks for about 5 years that _none_ ever got corrupted. Not a single one in 5 years. Taking into account that CF is really no big hit in technology most people really only talking about fearing the black man when talking about flash disks of any kind. Please stop FUD and simply buy acceptable vendors. If you want to see real trouble then buy W* green IT 2 TB. I crashed 5 in a row within the first 3 months of usage. -- Regards, Stephan
Re: [Dovecot] Easy way to make all mailboxes of a user read-only
On Thu, 11 Apr 2013 16:35:32 +0300 Timo Sirainen wrote: > On 11.4.2013, at 16.24, Stephan von Krawczynski wrote: > > >> The MTA can work as it used to, if it can just set a group-read permission > >> to the files. So your read-only user would belong to that read-only-group. > >> I'm not sure how Postfix assigns permissions, but if it can't do that you > >> could switch to Dovecot LDA/LMTP which can set the group correctly. > > > > That is not the problem. I can set any type of permission on the mail file > > itself. Only it does not help because dovecot nevertheless is able to move > > the > > mails around or "delete" them by moving to trash box. > > No, the idea was to use two UNIX users: > > 1) the user that owns the mails and has read-write acces > > 2) another read-only user that does not own the mails, has only group-read > access. can't do anything at all to the mails. > > The directories need to have similar permissions as well (750). That's about as complicated as patching the MTA to auto-create the acl file, which I did now. I'd say global acls would be a nice coming feature ;-) -- Regards, Stephan
Re: [Dovecot] Easy way to make all mailboxes of a user read-only
On Thu, 11 Apr 2013 16:15:23 +0300 Timo Sirainen wrote: > On 11.4.2013, at 16.07, Stephan von Krawczynski wrote: > > > On Thu, 11 Apr 2013 16:00:22 +0300 > > Timo Sirainen wrote: > > > >> On 11.4.2013, at 15.07, Stephan von Krawczynski wrote: > >> > >>> I try to configure dovecot to make all imap accesses read-only for a > >>> certain > >>> user. I thought this would be possible by creating a global acl file (here > >>> "global-acl") like: > >> > >> Sorry, there is still no "default ACLs" feature in Dovecot. The only > >> semi-easy way to do what you want is using filesystem permissions. > >> > >> This is something that really should be developed though.. But probably > >> not until v2.3. > > > > Oh, that is _bad_. I cannot use fs permissions because the MTA (postfix) > > must > > have write permissions (to the directories) to create the mail files... > > The MTA can work as it used to, if it can just set a group-read permission to > the files. So your read-only user would belong to that read-only-group. I'm > not sure how Postfix assigns permissions, but if it can't do that you could > switch to Dovecot LDA/LMTP which can set the group correctly. That is not the problem. I can set any type of permission on the mail file itself. Only it does not help because dovecot nevertheless is able to move the mails around or "delete" them by moving to trash box. -- Regards, Stephan
Re: [Dovecot] Easy way to make all mailboxes of a user read-only
On Thu, 11 Apr 2013 16:00:22 +0300 Timo Sirainen wrote: > On 11.4.2013, at 15.07, Stephan von Krawczynski wrote: > > > I try to configure dovecot to make all imap accesses read-only for a certain > > user. I thought this would be possible by creating a global acl file (here > > "global-acl") like: > > Sorry, there is still no "default ACLs" feature in Dovecot. The only > semi-easy way to do what you want is using filesystem permissions. > > This is something that really should be developed though.. But probably not > until v2.3. And I just checked another thing: Though setting permissions to 400 the owner still can move mails to trash (seems to be a rename?). That is definitely not read-only. -- Regards, Stephan
Re: [Dovecot] Easy way to make all mailboxes of a user read-only
On Thu, 11 Apr 2013 15:08:31 +0200 Reindl Harald wrote: > > > Am 11.04.2013 15:05, schrieb Stephan von Krawczynski: > > Let me explain some more details, that seem important to understand: > > > > I cannot use acl files per folder/mailbox because the MTA creates folders > > dynamically (re-orders mails in folders) > > why does the MTA that? > > normally the MTA should only decide reject or accept a message > and deliver it via LMTP to the LDA which can then filter via > Sieve or whatever and from this moment on any dynamically > created folder would be created in the dovecot world I cannot further explain the background, you have to believe that there is a good reason for this implementation. It is no standard mail service. -- Regards, Stephan
Re: [Dovecot] Easy way to make all mailboxes of a user read-only
On Thu, 11 Apr 2013 16:00:22 +0300 Timo Sirainen wrote: > On 11.4.2013, at 15.07, Stephan von Krawczynski wrote: > > > I try to configure dovecot to make all imap accesses read-only for a certain > > user. I thought this would be possible by creating a global acl file (here > > "global-acl") like: > > Sorry, there is still no "default ACLs" feature in Dovecot. The only > semi-easy way to do what you want is using filesystem permissions. > > This is something that really should be developed though.. But probably not > until v2.3. Oh, that is _bad_. I cannot use fs permissions because the MTA (postfix) must have write permissions (to the directories) to create the mail files... -- Regards, Stephan
Re: [Dovecot] Easy way to make all mailboxes of a user read-only
Let me explain some more details, that seem important to understand: I cannot use acl files per folder/mailbox because the MTA creates folders dynamically (re-orders mails in folders). So I really would need some idea to tell dovecot to let a certain user access his mailbox/folders read-only, no matter how many. A global acl _file_ would do that, or an acl-file that work for a whole tree of folders. A global acl directory does not help, because I would have to know the names of every single folder/mailbox to create the correct acl-file in the global directory. -- Regards, Stephan
[Dovecot] Easy way to make all mailboxes of a user read-only
Hello all, I try to configure dovecot to make all imap accesses read-only for a certain user. I thought this would be possible by creating a global acl file (here "global-acl") like: user= lr and plugin { acl = vfile:/etc/dovecot/global-acls:cache_secs=300 } But that seems to be ignored. What is wrong with this idea, the docs are not really clear about a single acl file with global settings. -- Regards, Stephan
Re: [Dovecot] How to see folders/subfolders/emails through imap
On Wed, 10 Apr 2013 11:36:24 +0300 Timo Sirainen wrote: > On 10.4.2013, at 11.21, Stephan von Krawczynski wrote: > > > Sorry, it seems not that easy. > > I had to find out that sylpheed works correctly now, but thunderbird does > > not > > show anything, just like before. > > Is there a way to log all imap commands and replies? > > http://wiki2.dovecot.org/Debugging/Rawlog > > Either you have set a namespace prefix to Thunderbird, or it's listing only > subscribed folders and you don't have any subscriptions. You are right. In the meantime I found out that the default config in thunderbird lists only subscribed folders. Changing this setting makes it work as expected. Thank you for your hint. -- Regards, Stephan
Re: [Dovecot] How to see folders/subfolders/emails through imap
On Tue, 9 Apr 2013 22:07:01 +0200 Stephan von Krawczynski wrote: > On Tue, 09 Apr 2013 21:19:25 +0200 > Steffen wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Stephan von Krawczynski wrote: > > > On Tue, 9 Apr 2013 16:50:40 +0200 (CEST) Steffen Kaiser > > > wrote: > > > > > I tried to tell dovecot that is > > > mail_location=maildir::LAYOUT=fs > > > > Works for me, Dovecot v2.2RC3 > > > > mail_location = maildir:/home/fs:LAYOUT=fs > > mkdir -p /home/fs/foo/{tmp,cur,new} > > mkdir -p /home/fs/foo/bar/{tmp,cur,new} > > > > telnet localhost 143 > > 0 login nnn nnn > > 1 list "" "*" > > * LIST (\HasChildren) "/" foo > > * LIST (\HasNoChildren) "/" foo/bar > > * LIST (\HasNoChildren) "/" INBOX > > 1 OK List completed. > > Ok, I solved it thanks to your striking example. The problem was: the clients > remembered something from earlier sessions where the dovecot config was > probably not correct. I removed the mailbox from the client and recreated it > and now I see the correct list of folders. Thanks a lot for this hint. Sorry, it seems not that easy. I had to find out that sylpheed works correctly now, but thunderbird does not show anything, just like before. Is there a way to log all imap commands and replies? -- Regards, Stephan
Re: [Dovecot] How to see folders/subfolders/emails through imap
On Tue, 09 Apr 2013 21:19:25 +0200 Steffen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Stephan von Krawczynski wrote: > > On Tue, 9 Apr 2013 16:50:40 +0200 (CEST) Steffen Kaiser > > wrote: > > > I tried to tell dovecot that is > > mail_location=maildir::LAYOUT=fs > > Works for me, Dovecot v2.2RC3 > > mail_location = maildir:/home/fs:LAYOUT=fs > mkdir -p /home/fs/foo/{tmp,cur,new} > mkdir -p /home/fs/foo/bar/{tmp,cur,new} > > telnet localhost 143 > 0 login nnn nnn > 1 list "" "*" > * LIST (\HasChildren) "/" foo > * LIST (\HasNoChildren) "/" foo/bar > * LIST (\HasNoChildren) "/" INBOX > 1 OK List completed. Ok, I solved it thanks to your striking example. The problem was: the clients remembered something from earlier sessions where the dovecot config was probably not correct. I removed the mailbox from the client and recreated it and now I see the correct list of folders. Thanks a lot for this hint. -- Regards, Stephan
Re: [Dovecot] How to see folders/subfolders/emails through imap
On Tue, 9 Apr 2013 16:50:40 +0200 (CEST) Steffen Kaiser wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mon, 8 Apr 2013, Stephan von Krawczynski wrote: > > > I am trying to do something very simple - at least thats what I thought. > > I have some fs, it contains folders and subfolders with email files ordered > > like maildir. Now I try to set up dovecot on top simply to let some imap > > account watch these email files. But I cannot see any folders at all. I can > > create new folders and see them, but I cannot create subfolders as subdirs > > like "folder/subfolder". Instead I get "folder.subfolder" dirs on the fs. > > I tried to set the separator to "/", but that does not help at all. > > > > Is there some easy way to configure dovecot to display: > > > > ///new/files... > >/new/files... > >/new/files... > > > > according to fs layout on some imap-client (like thunderbird)? > > Well, first, simply explain what you mean with "email files". > > a) you mentioned "maildir", so simply look at > http://wiki2.dovecot.org/MailLocation/Maildir "Directory layout" > this would also fit your example, IMHO. Ok, I thought the setup was pretty clear, but let me give more details. I have _no_ problem with understanding the several maildir formats, I am here using maildir (not ++). LAYOUT=fs therefore. My expectation was that directories would be shown as folders through imap. But they are in fact not shown at all, neither in thunderbird nor in sylpheed (to name another client). > b) you mentioned "thunderbird", which does not use maildir to my > knowledge, but mbox, so simply look at > http://wiki2.dovecot.org/MailLocation/mbox > > You might want to place control files somewhere else, see CONTROL= and > INDEX=. Uh? thunderbird is a client, the client should not bother at all about maildir or mbox on the server. Again, assume I have a mailserver. The MTA produces directories like: ///new/ ...//new/ ... ...//new/ (clearly a maildir-alike format) Now on this server I want dovecot to hand this layout to some email-client (on another box, lets say some wind*ws), thunderbird if possible, via imap. That's about all. I tried to tell dovecot that is mail_location=maildir::LAYOUT=fs Yes, there is only _one_ user. My expectation was to see as imap-folder but I see exactly zero. If I try to create a new folder from thunderbird side a directory is created inside , so generally dovecot understood the idea, only directories that are already there are not shown. -- Regards, Stephan
[Dovecot] How to see folders/subfolders/emails through imap
Hello all, I am trying to do something very simple - at least thats what I thought. I have some fs, it contains folders and subfolders with email files ordered like maildir. Now I try to set up dovecot on top simply to let some imap account watch these email files. But I cannot see any folders at all. I can create new folders and see them, but I cannot create subfolders as subdirs like "folder/subfolder". Instead I get "folder.subfolder" dirs on the fs. I tried to set the separator to "/", but that does not help at all. Is there some easy way to configure dovecot to display: ///new/files... /new/files... /new/files... according to fs layout on some imap-client (like thunderbird)? -- Regards, Stephan