Post-Auth external check?

[Stephan von Krawczynski]

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

[Stephan von Krawczynski via 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

[Stephan von Krawczynski via 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

[Stephan von Krawczynski via dovecot]

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

[Stephan von Krawczynski via dovecot]

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?

[Stephan von Krawczynski]

On Mon, 20 Nov 2017 12:05:46 +0200
Sami Ketola <sami.ket...@dovecot.fi> wrote:

> > On 20 Nov 2017, at 10.50, Stephan von Krawczynski <skraw...@ithnet.com>
> > 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?

[Stephan von Krawczynski]

On Tue, 7 Nov 2017 21:40:55 +0200
Timo Sirainen <t...@iki.fi> wrote:

> On 7 Nov 2017, at 21.33, Stephan von Krawczynski <skraw...@ithnet.com> 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?

[Stephan von Krawczynski]

On Fri, 10 Nov 2017 03:41:20 -0500
Bill Shirley <b...@knoxvillechristian.org> 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 <b...@knoxvillechristian.org> 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?

[Stephan von Krawczynski]

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?

[Stephan von Krawczynski]

On Tue, 7 Nov 2017 19:19:23 +0200
Timo Sirainen <t...@iki.fi> wrote:

> On 7 Nov 2017, at 9.15, Stephan von Krawczynski <skraw...@ithnet.com> wrote:
> > 
> > On Tue, 07 Nov 2017 13:19:12 +1000
> > Noel Butler <noel.but...@ausics.net> 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?

[Stephan von Krawczynski]

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?

[Stephan von Krawczynski]

On Mon, 6 Nov 2017 09:50:16 -0500
Tanstaafl <tansta...@libertytrek.org> wrote:

> On 11/6/2017, 4:01:19 AM, Stephan von Krawczynski <skraw...@ithnet.com>
> 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?

[Stephan von Krawczynski]

On Mon, 6 Nov 2017 08:37:11 +0200
Sami Ketola <sami.ket...@dovecot.fi> wrote:

> > On 5 Nov 2017, at 12.55, Stephan von Krawczynski <skraw...@ithnet.com>
> > 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?

[Stephan von Krawczynski]

On Sun, 5 Nov 2017 10:44:25 +0200
Sami Ketola <sami.ket...@dovecot.fi> wrote:

> > On 4 Nov 2017, at 10.31, Stephan von Krawczynski <skraw...@ithnet.com>
> > wrote:
> > 
> > On Sat, 4 Nov 2017 01:57:31 +0200
> > Sami Ketola <sami.ket...@dovecot.fi> 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?

[Stephan von Krawczynski]

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?

[Stephan von Krawczynski]

On Fri, 3 Nov 2017 19:30:22 +0200
Sami Ketola <sami.ket...@dovecot.fi> wrote:

> > On 3 Nov 2017, at 18.23, Stephan von Krawczynski <skraw...@ithnet.com>
> > 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?

[Stephan von Krawczynski]

On Fri, 3 Nov 2017 17:53:47 +0200 (EET)
Aki Tuomi <aki.tu...@dovecot.fi> wrote:

> > On November 3, 2017 at 1:50 PM Stephan von Krawczynski
> > <skraw...@ithnet.com> 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 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?

[Stephan von Krawczynski]

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 to work.
Your opinion?

-- 
Regards,
Stephan

Re: is a self signed certificate always invalid the first time

[Stephan von Krawczynski]

On Sun, 20 Aug 2017 12:29:49 -0400
KT Walrus <ke...@my.walr.us> wrote:

> > On Aug 20, 2017, at 11:52 AM, Stephan von Krawczynski <sk...@ithnet.com>
> > wrote:
> > 
> > On Sat, 19 Aug 2017 21:39:18 -0400
> > KT Walrus <ke...@my.walr.us> wrote:
> >   
> >>> On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski <sk...@ithnet.com>
> >>> wrote:
> >>> 
> >>> On Fri, 18 Aug 2017 00:24:39 -0700 (PDT)
> >>> Joseph Tam <jtam.h...@gmail.com> wrote:
> >>>   
> >>>> Michael Felt <mich...@felt.demon.nl> 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 <jtam.h...@gmail.com>
> >>> 
> >>> 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

[Stephan von Krawczynski]

On Sat, 19 Aug 2017 21:39:18 -0400
KT Walrus <ke...@my.walr.us> wrote:

> > On Aug 18, 2017, at 4:05 AM, Stephan von Krawczynski <sk...@ithnet.com>
> > wrote:
> > 
> > On Fri, 18 Aug 2017 00:24:39 -0700 (PDT)
> > Joseph Tam <jtam.h...@gmail.com> wrote:
> >   
> >> Michael Felt <mich...@felt.demon.nl> 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 <jtam.h...@gmail.com>  
> > 
> > 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

[Stephan von Krawczynski]

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?

[Stephan von Krawczynski]

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?

[Stephan von Krawczynski]

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

[Stephan von Krawczynski]

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

[Stephan von Krawczynski]

On Sat, 19 Mar 2016 17:37:04 +1000
Noel Butler <noel.but...@ausics.net> 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

[Stephan von Krawczynski]

On Mon, 14 Mar 2016 16:59:28 +1000
Noel Butler <noel.but...@ausics.net> wrote:

> On 14/03/2016 09:59, Stephan von Krawczynski wrote:
> > On Mon, 14 Mar 2016 09:32:42 +1000
> > Noel Butler <noel.but...@ausics.net> wrote:
> > 
> >> On 13/03/2016 20:47, Stephan von Krawczynski wrote:
> >> > On Sun, 13 Mar 2016 09:45:06 +
> >> > James <li...@xdrv.co.uk> 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

[Stephan von Krawczynski]

On Mon, 14 Mar 2016 09:32:42 +1000
Noel Butler <noel.but...@ausics.net> wrote:

> On 13/03/2016 20:47, Stephan von Krawczynski wrote:
> > On Sun, 13 Mar 2016 09:45:06 +
> > James <li...@xdrv.co.uk> 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

[Stephan von Krawczynski]

On Sun, 13 Mar 2016 11:47:23 +0100
Stephan von Krawczynski <sk...@ithnet.com> wrote:

> On Sun, 13 Mar 2016 09:45:06 +
> James <li...@xdrv.co.uk> 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

[Stephan von Krawczynski]

On Sun, 13 Mar 2016 09:45:06 +
James <li...@xdrv.co.uk> 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

[Stephan von Krawczynski]

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?

[Stephan von Krawczynski]

On Tue, 24 Jun 2014 17:03:09 +0200
Patrick De Zordo patr...@spamreducer.eu 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

[Dovecot] How to bring dovecot to using a slightly modified passwd file

[Stephan von Krawczynski]

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] How to bring dovecot to using a slightly modified passwd file

[Stephan von Krawczynski]

On Mon, 21 Apr 2014 13:38:59 +0200
Benny Pedersen m...@junc.eu 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

Re: [Dovecot] How to bring dovecot to using a slightly modified passwd file

[Stephan von Krawczynski]

On Mon, 21 Apr 2014 17:26:13 +0200
Andreas Schulze s...@andreasschulze.de 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] Changing SSL certificates - switching from self-signed to RapidSSL

[Stephan von Krawczynski]

On Fri, 18 Apr 2014 13:57:47 -0400
Charles Marcus cmar...@media-brokers.com 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] Changing SSL certificates - switching from self-signed to RapidSSL

[Stephan von Krawczynski]

On Sat, 19 Apr 2014 09:22:07 +0200
Reindl Harald h.rei...@thelounge.net wrote:

 
 
 Am 19.04.2014 09:14, schrieb Stephan von Krawczynski:
  On Fri, 18 Apr 2014 13:57:47 -0400
  Charles Marcus cmar...@media-brokers.com 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

[Stephan von Krawczynski]

On Sat, 19 Apr 2014 09:40:07 +0200
Reindl Harald h.rei...@thelounge.net 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

[Stephan von Krawczynski]

On Sat, 19 Apr 2014 10:20:39 +0200
Reindl Harald h.rei...@thelounge.net 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] OT/about SSDs

[Stephan von Krawczynski]

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

[Dovecot] Easy way to make all mailboxes of a user read-only

[Stephan von Krawczynski]

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=username 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] Easy way to make all mailboxes of a user read-only

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

Re: [Dovecot] Easy way to make all mailboxes of a user read-only

[Stephan von Krawczynski]

On Thu, 11 Apr 2013 16:00:22 +0300
Timo Sirainen t...@iki.fi wrote:

 On 11.4.2013, at 15.07, Stephan von Krawczynski sk...@ithnet.com 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

[Stephan von Krawczynski]

On Thu, 11 Apr 2013 15:08:31 +0200
Reindl Harald h.rei...@thelounge.net 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

[Stephan von Krawczynski]

On Thu, 11 Apr 2013 16:00:22 +0300
Timo Sirainen t...@iki.fi wrote:

 On 11.4.2013, at 15.07, Stephan von Krawczynski sk...@ithnet.com 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

[Stephan von Krawczynski]

On Thu, 11 Apr 2013 16:15:23 +0300
Timo Sirainen t...@iki.fi wrote:

 On 11.4.2013, at 16.07, Stephan von Krawczynski sk...@ithnet.com wrote:
 
  On Thu, 11 Apr 2013 16:00:22 +0300
  Timo Sirainen t...@iki.fi wrote:
  
  On 11.4.2013, at 15.07, Stephan von Krawczynski sk...@ithnet.com 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

[Stephan von Krawczynski]

On Thu, 11 Apr 2013 16:35:32 +0300
Timo Sirainen t...@iki.fi wrote:

 On 11.4.2013, at 16.24, Stephan von Krawczynski sk...@ithnet.com 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] How to see folders/subfolders/emails through imap

[Stephan von Krawczynski]

On Tue, 9 Apr 2013 22:07:01 +0200
Stephan von Krawczynski sk...@ithnet.com wrote:

 On Tue, 09 Apr 2013 21:19:25 +0200
 Steffen skdove...@smail.inf.fh-brs.de wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  Stephan von Krawczynski wrote:
   On Tue, 9 Apr 2013 16:50:40 +0200 (CEST) Steffen Kaiser
   skdove...@smail.inf.fh-brs.de wrote:
  
   I tried to tell dovecot that spooldir is 
   mail_location=maildir:spooldir: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

[Stephan von Krawczynski]

On Wed, 10 Apr 2013 11:36:24 +0300
Timo Sirainen t...@iki.fi wrote:

 On 10.4.2013, at 11.21, Stephan von Krawczynski sk...@ithnet.com 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

[Stephan von Krawczynski]

On Tue, 9 Apr 2013 16:50:40 +0200 (CEST)
Steffen Kaiser skdove...@smail.inf.fh-brs.de 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:
 
  somedir/folder1/subfolder1/new/files...
 subfolder2/new/files...
 subfolder3/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:

spooldir/folder/subfolder1/new/some-email-file
.../subfolder2/new/another-email-file
   ...
.../subfolderX/new/again-some-mail-file


(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 spooldir is
mail_location=maildir:spooldir:LAYOUT=fs
Yes, there is only _one_ user. My expectation was to see folder as
imap-folder but I see exactly zero. If I try to create a new folder from
thunderbird side a directory is created inside spooldir, so generally
dovecot understood the idea, only directories that are already there are not
shown.

-- 
Regards,
Stephan

Re: [Dovecot] How to see folders/subfolders/emails through imap

[Stephan von Krawczynski]

On Tue, 09 Apr 2013 21:19:25 +0200
Steffen skdove...@smail.inf.fh-brs.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Stephan von Krawczynski wrote:
  On Tue, 9 Apr 2013 16:50:40 +0200 (CEST) Steffen Kaiser
  skdove...@smail.inf.fh-brs.de wrote:
 
  I tried to tell dovecot that spooldir is 
  mail_location=maildir:spooldir: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

[Dovecot] How to see folders/subfolders/emails through imap

[Stephan von Krawczynski]

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:

somedir/folder1/subfolder1/new/files...
subfolder2/new/files...
subfolder3/new/files...

according to fs layout on some imap-client (like thunderbird)?

-- 
Regards,
Stephan