\Noselect isn't set on namespace prefix mailbox that can't be selected

[David Mandelberg]

Hi,

I tried using Nextcloud's Mail app to access my dovecot server (version: 
2.2.27 (c0f36b0)), and got an error. The relevant imap log is:


C: 3 LIST () "" (*) RETURN (SPECIAL-USE)
...
S: * LIST () "/" Archives
...
C: 6 STATUS Archives (MESSAGES)
S: 6 NO Mailbox isn't selectable (0.000 + 0.000 secs).
>> Command 6 took 0.0014 seconds.
C: 7 LOGOUT
S: * BYE Logging out
S: 7 OK Logout completed (0.000 + 0.000 secs).
>> Command 7 took 0.0021 seconds.

And the relevant part of my dovecot config:

namespace archives {
  disabled = no
  hidden = no
  ignore_on_failure = no
  inbox = no
  list = yes
  location = mbox:~/.mbox-archives
  order = 0
  prefix = Archives/
  separator = /
  subscriptions = yes
  type = private
}

Since ~/.mbox-archives is a directory, not a regular file, I'd expect 
dovecot to set the \Noselect attribute on the Archives folder. Is there 
something I'm missing? I tried using special_use, but that didn't accept 
\Noselect as an option.

Re: Dovecot mail_location for fedora

[Noel Butler]

On 19/08/2017 07:17, Joseph Tam wrote:

> mail_location=~/.mail:INBOX=/var/spool/mail/%Ln 
> He should be good now, no idea why a fedora install wouldn't have that

Unless I missed something in a previous pst, "~/.mail" is not typical
for personal mail folder, but "~/mail" is.

Joseph Tam  

I thought that (from earlier example), but not having used mbox in 10
years, couldnt remember, I couldn't example mine because that would
throw OP completely 

(mail_location =
maildir:/var/vmail/%Ld/%1Ln/%1.1Ln/%2.1Ln/%Ln/Maildir:INDEX=MEMORY)

Since he's not replied, I dare say Aki's post helped him sort it out. 

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

Permission denied to access the email file

[ATHANASE Jean-René]

Hi,

Dovecot version : 2.2.22 (fe789d2)
Operating system :
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
CPU architecture : Linux 4.4.67-1-pve #1 SMP PVE 4.4.67-92 (Fri, 23 Jun 
2017 08:22:06 +0200) x86_64 GNU/Linux

FIle system : local

UIDGID
Aug 17 11:47:28 azizee dovecot: imap(jra11[*5063*:*5011*]): Debug: 
Effective uid=5063, gid=5011, home=/var/spool/domaines/vitalnet/jra/
Aug 17 11:47:28 azizee dovecot: imap(jra11[5063:5011]): Debug: Namespace 
inbox: type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes, 
subscriptions=yes location=maildir:/var/spool/domaines/vitalnet/jra/
Aug 17 11:47:28 azizee dovecot: imap(jra11[5063:5011]): Debug: 
maildir++: root=/var/spool/domaines/vitalnet/jra, index=, indexpvt=, 
control=, inbox=/var/spool/domaines/vitalnet/jra, alt=
Aug 17 11:47:28 azizee dovecot: imap(jra11[5063:5011]): *Error*: 
open(/var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee:2,) 
failed: *Permission denied* (euid=*5063*() 
egid=*5011*() missing +r perm: 
/var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee:2,)


Ldap configuration :
  user_attrs = 
uid=user,userPassword=password,homeDirectory=home,uidNumber=uid,gidNumber=gid


ll 
/var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee\:2\,
-rw--- 1 5095 5011 438 Aug 16 15:29 
/var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee:2,



If I set with the command line "chmod g=rw 
/var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee\:2\,", 
this file email is treated by Dovecot, per example, i have deleted it.


ll 
/var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee\:2\,ST 

-rw-rw 1 5095 5011 438 Aug 16 15:29 
/var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee:2,ST


What's the problem of my configuration ?

Best regards,

Re: Dovecot mail_location for fedora

[Joseph Tam]

mail_location=~/.mail:INBOX=/var/spool/mail/%Ln


He should be good now, no idea why a fedora install wouldn't have that


Unless I missed something in a previous pst, "~/.mail" is not typical
for personal mail folder, but "~/mail" is.

Joseph Tam 

Re: Inconsistency in map index

[Webert de Souza Lima]

On Fri, Aug 18, 2017 at 1:30 PM, Timo Sirainen  wrote:

>
> That would work. Also as a different workaround you could just rm
> storage/dovecot.map.index* and doveadm force-resync -u user@domain '*'.



Thank you Timo, that did the trick without the need of a sudden upgrade.
Mailbox was fixed :)


Regards,

Webert Lima
DevOps Engineer at MAV Tecnologia
*Belo Horizonte - Brasil*

>
>

Re: Inconsistency in map index

[Timo Sirainen]

On 18 Aug 2017, at 16.43, Webert de Souza Lima  wrote:
> 
> On Fri, Aug 18, 2017 at 9:03 AM, Aki Tuomi  wrote:
> 
>> This is fixed in next release (2.2.32) with
>> https://github.com/dovecot/core/commit/c8be394
>> 
>> Aki Tuomi
>> 
> 
> As this is still a release candidate, I'm thinking of running an isolated
> instance of this version, and do doveadm force-resync just to fix just this
> user's mailbox.
> What do you think?

That would work. Also as a different workaround you could just rm 
storage/dovecot.map.index* and doveadm force-resync -u user@domain '*'. Should 
be also safe to do (won't lose any information), although I guess it has some 
potential of race conditions causing temporary problems if the user accesses 
mails at the same time.

Re: Install locks up my server

[Timo Sirainen]

No idea. config.guess is generated by autotools, so I don't think I can really 
affect it anyway. Also it works fine at least in CentOS 6.7 & 6.9. My guess is 
also that it might work ok in CentOS 6.6 and the brokenness is somehow specific 
to your system.

> On 18 Aug 2017, at 18.43, Marc Perkel  wrote:
> 
> This is still broken in the 2.2.32 release candidate. config.guess forks 
> copies till the server dies. Running Centos 6.6 under OpenVZ.
> 
> On 06/26/17 16:03, Marc Perkel wrote:
>> 
>> 
>> On 06/26/17 14:42, Timo Sirainen wrote:
>>> On 26 Jun 2017, at 23.19, Marc Perkel  wrote:
 Ever since 2.26 I haven't been able to upgrade. In fact the install locks 
 up my server.
 
 I get into and infinite recursive loop where the config-guess program 
 calls itself until the server locks up from overload.
 
 I'm running Centos 6 under OpenVZ.
 
 What am I missing? I think there's a serious bug.
 
 31233 pts/3S  0:00 /bin/sh ./config.guess
 31235 pts/3S  0:00  \_ /bin/sh ./config.guess
 31238 pts/3S  0:00  \_ /bin/sh ./config.guess
 31240 pts/3S  0:00  \_ /bin/sh ./config.guess
>>> I think I remember seeing this before, but unfortunately can't remember 
>>> what the solution was. Maybe it was something something messed up in the OS 
>>> or in the build directory. Are you compiling from the tarballs? So it's the 
>>> "configure" that fails? Also if you run "./config.guess" manually? What's 
>>> the output if you run "bash -x ./config.guess"?
>>> 
>>> 
>>> 
>> 
>> bash -x ./config.guess
>> + timestamp=2015-08-20
>> ++ sed -e 's,.*/,,'
>> ++ echo ./config.guess
>> + me=config.guess
>> + usage='Usage: ./config.guess [OPTION]
>> 
>> Output the configuration name of the system `config.guess'\'' is run on.
>> 
>> Operation modes:
>>  -h, --help print this help, then exit
>>  -t, --time-stamp   print date of last modification, then exit
>>  -v, --version  print version number, then exit
>> 
>> Report bugs and patches to .'
>> + version='GNU config.guess (2015-08-20)
>> 
>> Originally written by Per Bothner.
>> Copyright 1992-2015 Free Software Foundation, Inc.
>> 
>> This is free software; see the source for copying conditions. There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.'
>> + help='
>> Try `config.guess --help'\'' for more information.'
>> + test 0 -gt 0
>> + test 0 '!=' 0
>> + trap 'exit 1' 1 2 15
>> + set_cc_for_build='
>> trap "exitcode=\$?; (rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null) 
>> && exit \$exitcode" 0 ;
>> trap "rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null; exit 1" 1 2 13 
>> 15 ;
>> : ${TMPDIR=/tmp} ;
>> { tmp=`(umask 077 && mktemp -d "$TMPDIR/cgXX") 2>/dev/null` && test -n 
>> "$tmp" && test -d "$tmp" ; } ||
>> { test -n "$RANDOM" && tmp=$TMPDIR/cg$$-$RANDOM && (umask 077 && mkdir $tmp) 
>> ; } ||
>> { tmp=$TMPDIR/cg-$$ && (umask 077 && mkdir $tmp) && echo "Warning: creating 
>> insecure temp directory" >&2 ; } ||
>> { echo "$me: cannot create a temporary directory in $TMPDIR" >&2 ; exit 1 ; 
>> } ;
>> dummy=$tmp/dummy ;
>> tmpfiles="$dummy.c $dummy.o $dummy.rel $dummy" ;
>> case $CC_FOR_BUILD,$HOST_CC,$CC in
>> ,,)echo "int x;" > $dummy.c ;
>>for c in cc gcc c89 c99 ; do
>>  if ($c -c -o $dummy.o $dummy.c) >/dev/null 2>&1 ; then
>> CC_FOR_BUILD="$c"; break ;
>>  fi ;
>>done ;
>>if test x"$CC_FOR_BUILD" = x ; then
>>  CC_FOR_BUILD=no_compiler_found ;
>>fi
>>;;
>> ,,*)   CC_FOR_BUILD=$CC ;;
>> ,*,*)  CC_FOR_BUILD=$HOST_CC ;;
>> esac ; set_cc_for_build= ;'
>> + UNAME_MACHINE=x86_64
>> + UNAME_RELEASE=2.6.32-042stab123.3
>> + UNAME_SYSTEM=Linux
>> + UNAME_VERSION='#1 SMP Fri May 5 12:29:05 MSK 2017'
>> + case "${UNAME_SYSTEM}" in
>> + LIBC=gnu
>> + eval trap '"exitcode=\$?;' '(rm' -f '\$tmpfiles' '2>/dev/null;' rmdir 
>> '\$tmp' '2>/dev/null)' '&&' exit '\$exitcode"' 0 ';' trap '"rm' -f 
>> '\$tmpfiles' '2>/dev/null;' rmdir '\$tmp' '2>/dev/null;' exit '1"' 1 2 13 15 
>> ';' : '${TMPDIR=/tmp}' ';' '{' 'tmp=`(umask' 077 '&&' mktemp -d 
>> '"$TMPDIR/cgXX")' '2>/dev/null`' '&&' test -n '"$tmp"' '&&' test -d 
>> '"$tmp"' ';' '}' '||' '{' test -n '"$RANDOM"' '&&' 
>> 'tmp=$TMPDIR/cg$$-$RANDOM' '&&' '(umask' 077 '&&' mkdir '$tmp)' ';' '}' '||' 
>> '{' 'tmp=$TMPDIR/cg-$$' '&&' '(umask' 077 '&&' mkdir '$tmp)' '&&' echo 
>> '"Warning:' creating insecure temp 'directory"' '>&2' ';' '}' '||' '{' echo 
>> '"$me:' cannot create a temporary directory in '$TMPDIR"' '>&2' ';' exit 1 
>> ';' '}' ';' 'dummy=$tmp/dummy' ';' 'tmpfiles="$dummy.c' '$dummy.o' 
>> '$dummy.rel' '$dummy"' ';' case '$CC_FOR_BUILD,$HOST_CC,$CC' in ',,)' echo 
>> '"int' 'x;"' '>' '$dummy.c' ';' for c in cc gcc c89 c99 ';' do if '($c' -c 
>> -o '$dummy.o' '$dummy.c)' '>/dev/null' '2>&1' ';' then 'CC_FOR_BUILD="$c";' 
>> break ';' fi ';' done ';' if test 

Re: Install locks up my server

[Marc Perkel]

This is still broken in the 2.2.32 release candidate. config.guess forks 
copies till the server dies. Running Centos 6.6 under OpenVZ.


On 06/26/17 16:03, Marc Perkel wrote:



On 06/26/17 14:42, Timo Sirainen wrote:

On 26 Jun 2017, at 23.19, Marc Perkel  wrote:
Ever since 2.26 I haven't been able to upgrade. In fact the install 
locks up my server.


I get into and infinite recursive loop where the config-guess 
program calls itself until the server locks up from overload.


I'm running Centos 6 under OpenVZ.

What am I missing? I think there's a serious bug.

31233 pts/3S  0:00 /bin/sh ./config.guess
31235 pts/3S  0:00  \_ /bin/sh ./config.guess
31238 pts/3S  0:00  \_ /bin/sh ./config.guess
31240 pts/3S  0:00  \_ /bin/sh ./config.guess
I think I remember seeing this before, but unfortunately can't 
remember what the solution was. Maybe it was something something 
messed up in the OS or in the build directory. Are you compiling from 
the tarballs? So it's the "configure" that fails? Also if you run 
"./config.guess" manually? What's the output if you run "bash -x 
./config.guess"?






bash -x ./config.guess
+ timestamp=2015-08-20
++ sed -e 's,.*/,,'
++ echo ./config.guess
+ me=config.guess
+ usage='Usage: ./config.guess [OPTION]

Output the configuration name of the system `config.guess'\'' is run on.

Operation modes:
  -h, --help print this help, then exit
  -t, --time-stamp   print date of last modification, then exit
  -v, --version  print version number, then exit

Report bugs and patches to .'
+ version='GNU config.guess (2015-08-20)

Originally written by Per Bothner.
Copyright 1992-2015 Free Software Foundation, Inc.

This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.'

+ help='
Try `config.guess --help'\'' for more information.'
+ test 0 -gt 0
+ test 0 '!=' 0
+ trap 'exit 1' 1 2 15
+ set_cc_for_build='
trap "exitcode=\$?; (rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 
2>/dev/null) && exit \$exitcode" 0 ;
trap "rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null; exit 1" 1 
2 13 15 ;

: ${TMPDIR=/tmp} ;
 { tmp=`(umask 077 && mktemp -d "$TMPDIR/cgXX") 2>/dev/null` && 
test -n "$tmp" && test -d "$tmp" ; } ||
 { test -n "$RANDOM" && tmp=$TMPDIR/cg$$-$RANDOM && (umask 077 && 
mkdir $tmp) ; } ||
 { tmp=$TMPDIR/cg-$$ && (umask 077 && mkdir $tmp) && echo "Warning: 
creating insecure temp directory" >&2 ; } ||
 { echo "$me: cannot create a temporary directory in $TMPDIR" >&2 ; 
exit 1 ; } ;

dummy=$tmp/dummy ;
tmpfiles="$dummy.c $dummy.o $dummy.rel $dummy" ;
case $CC_FOR_BUILD,$HOST_CC,$CC in
 ,,)echo "int x;" > $dummy.c ;
for c in cc gcc c89 c99 ; do
  if ($c -c -o $dummy.o $dummy.c) >/dev/null 2>&1 ; then
 CC_FOR_BUILD="$c"; break ;
  fi ;
done ;
if test x"$CC_FOR_BUILD" = x ; then
  CC_FOR_BUILD=no_compiler_found ;
fi
;;
 ,,*)   CC_FOR_BUILD=$CC ;;
 ,*,*)  CC_FOR_BUILD=$HOST_CC ;;
esac ; set_cc_for_build= ;'
+ UNAME_MACHINE=x86_64
+ UNAME_RELEASE=2.6.32-042stab123.3
+ UNAME_SYSTEM=Linux
+ UNAME_VERSION='#1 SMP Fri May 5 12:29:05 MSK 2017'
+ case "${UNAME_SYSTEM}" in
+ LIBC=gnu
+ eval trap '"exitcode=\$?;' '(rm' -f '\$tmpfiles' '2>/dev/null;' 
rmdir '\$tmp' '2>/dev/null)' '&&' exit '\$exitcode"' 0 ';' trap '"rm' 
-f '\$tmpfiles' '2>/dev/null;' rmdir '\$tmp' '2>/dev/null;' exit '1"' 
1 2 13 15 ';' : '${TMPDIR=/tmp}' ';' '{' 'tmp=`(umask' 077 '&&' mktemp 
-d '"$TMPDIR/cgXX")' '2>/dev/null`' '&&' test -n '"$tmp"' '&&' 
test -d '"$tmp"' ';' '}' '||' '{' test -n '"$RANDOM"' '&&' 
'tmp=$TMPDIR/cg$$-$RANDOM' '&&' '(umask' 077 '&&' mkdir '$tmp)' ';' 
'}' '||' '{' 'tmp=$TMPDIR/cg-$$' '&&' '(umask' 077 '&&' mkdir '$tmp)' 
'&&' echo '"Warning:' creating insecure temp 'directory"' '>&2' ';' 
'}' '||' '{' echo '"$me:' cannot create a temporary directory in 
'$TMPDIR"' '>&2' ';' exit 1 ';' '}' ';' 'dummy=$tmp/dummy' ';' 
'tmpfiles="$dummy.c' '$dummy.o' '$dummy.rel' '$dummy"' ';' case 
'$CC_FOR_BUILD,$HOST_CC,$CC' in ',,)' echo '"int' 'x;"' '>' '$dummy.c' 
';' for c in cc gcc c89 c99 ';' do if '($c' -c -o '$dummy.o' 
'$dummy.c)' '>/dev/null' '2>&1' ';' then 'CC_FOR_BUILD="$c";' break 
';' fi ';' done ';' if test 'x"$CC_FOR_BUILD"' = x ';' then 
CC_FOR_BUILD=no_compiler_found ';' fi ';;' ',,*)' 'CC_FOR_BUILD=$CC' 
';;' ',*,*)' 'CC_FOR_BUILD=$HOST_CC' ';;' esac ';' set_cc_for_build= ';'
++ trap 'exitcode=$?; (rm -f $tmpfiles 2>/dev/null; rmdir $tmp 
2>/dev/null) && exit $exitcode' 0
++ trap 'rm -f $tmpfiles 2>/dev/null; rmdir $tmp 2>/dev/null; exit 1' 
1 2 13 15

++ : /tmp
++ tmp=/tmp/cgpmW24a
++ test -n /tmp/cgpmW24a
++ test -d /tmp/cgpmW24a
++ dummy=/tmp/cgpmW24a/dummy
++ tmpfiles='/tmp/cgpmW24a/dummy.c /tmp/cgpmW24a/dummy.o 
/tmp/cgpmW24a/dummy.rel /tmp/cgpmW24a/dummy'

++ case $CC_FOR_BUILD,$HOST_CC,$CC in
++ echo 'int x;'
++ for c in cc gcc c89 c99

Re: Inconsistency in map index

[Webert de Souza Lima]

On Fri, Aug 18, 2017 at 9:03 AM, Aki Tuomi  wrote:

> This is fixed in next release (2.2.32) with
> https://github.com/dovecot/core/commit/c8be394
>
> Aki Tuomi
>

As this is still a release candidate, I'm thinking of running an isolated
instance of this version, and do doveadm force-resync just to fix just this
user's mailbox.
What do you think?

Regards,

Webert Lima
DevOps Engineer at MAV Tecnologia
*Belo Horizonte - Brasil*

Re: Inconsistency in map index

[Webert de Souza Lima]

Oh, so that's likely a bug.
I was thinking it would require manual intervention to fix.

Great, I'll do an upgrade ASAP. Praised be Docker.

Thank you very much.


Regards,

Webert Lima
DevOps Engineer at MAV Tecnologia
*Belo Horizonte - Brasil*

On Fri, Aug 18, 2017 at 9:03 AM, Aki Tuomi  wrote:

>
>
> On 18.08.2017 14:55, Webert de Souza Lima wrote:
> > Hello,
> >
> > The following errors are constantly popping up for 2 accounts. I can't
> get
> > it fixed,
> > I did doveadm backup to another account, the same happens in the new
> > account.
> > I did doveadm force-resync, the problem persists.
> >
> > I'm using dovecot 2.2.
> >
> > 2017-08-18T11:46:12.472821881Z Aug 18 11:46:12 lmtp(
> ramon.lace...@alliar.com):
> > Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage:
> > Inconsistency in map index (647,6288 != 647,28333584)
> >
> > 2017-08-18T11:46:12.651002372Z Aug 18 11:46:12 lmtp(
> ramon.lace...@alliar.com):
> > Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage:
> > Inconsistency in map index (647,6288 != 647,28333708)
> >
> > 2017-08-18T11:46:12.651059432Z Aug 18 11:46:12 lmtp(
> ramon.lace...@alliar.com):
> > Warning: fscking index file /srv/dovecot2/index/
> > alliar.com/ramon.lacerda/storage/dovecot.map.index
> >
> > 2017-08-18T11:46:12.764926940Z Aug 18 11:46:12 lmtp(
> ramon.lace...@alliar.com):
> > Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage:
> > rebuilding indexes
> >
> >
> > Regards,
> >
> > Webert Lima
> > DevOps Engineer at MAV Tecnologia
> > *Belo Horizonte - Brasil*
>
> Hi!
>
> This is fixed in next release (2.2.32) with
> https://github.com/dovecot/core/commit/c8be394
>
> Aki Tuomi
>

Re: /var/run/dovecot permission issues

[Bill Shirley]

I'm glad to read this thread.  I didn't even know that dovecot stats existed.

Which statistics do you find most useful?

Bill

On 8/17/2017 3:31 PM, Matt Simpson wrote:

On Aug 17, 2017, at 12:07 PM, Larry Rosenman  wrote:

In /usr/local/etc/dovecot/conf.d/90-plugin.conf:

Thanks.  Those config statements fixed the problem.

Filter of old Thunderbird installation interferes with lmtp/ Mail delivery / sieve

[Jürgen Gmach]

# 2.2.13: /etc/dovecot/dovecot.conf
# OS: Linux 4.9.25 i686 Gentoo Base System release 2.2
# pidgeonhole v0.4.3
# Thunderbird 3.0.4

impact
--
Emails, for which the filter applies, gets copied to the desired folder, 
but get kept in the inbox with deleted flag (in Roundcube you see them 
grayed out a bit, in Thunderbird they are not shown at all).


When the incoming email is from an internal mailing list (mailman), 
beginning with the user with the buggy Thunderbird all following emails 
of the internal users are flagged as deleted, but only if the user has a 
sieve file in their directory - no matter whether it is active or not.



After activating detailed logging the user with the "problematic" filter 
was found quickly.


The error is reproducible:
- install old Thunderbird version
- create filter
- write an email, which triggers the filter
-> email is flagged deleted but does not get deleted

Though, the user does not have a sieve file on our server, the filtering 
happened in the very same second when the email was delivered to the 
other colleagues.


Both Thunderbird and Pidgeonhole are outdated, so I am unsure if you are 
even interested in this bug report.


Fix
---
I made the user to update his Thunderbird version -> no more problems. 
Anyhow, a single "user interaction" should not be able to effect other 
mail accounts (ie Thunderbirds filter somehow disturbed the lmtp 
process).



--
Jürgen Gmach . juergen.gm...@apis.de . +49 9482 941545
APIS Informationstechnologien GmbH . http://www.apis.de
Gewerbepark A 13, 93086 Wörth/Donau . Deutschland
Sitz der GmbH: Wörth/Donau, Amtsgericht Regensburg (HRB 6684)
Geschäftsführer: Julia Anna Dietz, Jürgen Eilers, Peter Rosenbeck

Re: Inconsistency in map index

[Aki Tuomi]

On 18.08.2017 14:55, Webert de Souza Lima wrote:
> Hello,
>
> The following errors are constantly popping up for 2 accounts. I can't get
> it fixed,
> I did doveadm backup to another account, the same happens in the new
> account.
> I did doveadm force-resync, the problem persists.
>
> I'm using dovecot 2.2.
>
> 2017-08-18T11:46:12.472821881Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com):
> Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage:
> Inconsistency in map index (647,6288 != 647,28333584)
>
> 2017-08-18T11:46:12.651002372Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com):
> Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage:
> Inconsistency in map index (647,6288 != 647,28333708)
>
> 2017-08-18T11:46:12.651059432Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com):
> Warning: fscking index file /srv/dovecot2/index/
> alliar.com/ramon.lacerda/storage/dovecot.map.index
>
> 2017-08-18T11:46:12.764926940Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com):
> Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage:
> rebuilding indexes
>
>
> Regards,
>
> Webert Lima
> DevOps Engineer at MAV Tecnologia
> *Belo Horizonte - Brasil*

Hi!

This is fixed in next release (2.2.32) with
https://github.com/dovecot/core/commit/c8be394

Aki Tuomi

Inconsistency in map index

[Webert de Souza Lima]

Hello,

The following errors are constantly popping up for 2 accounts. I can't get
it fixed,
I did doveadm backup to another account, the same happens in the new
account.
I did doveadm force-resync, the problem persists.

I'm using dovecot 2.2.

2017-08-18T11:46:12.472821881Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com):
Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage:
Inconsistency in map index (647,6288 != 647,28333584)

2017-08-18T11:46:12.651002372Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com):
Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage:
Inconsistency in map index (647,6288 != 647,28333708)

2017-08-18T11:46:12.651059432Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com):
Warning: fscking index file /srv/dovecot2/index/
alliar.com/ramon.lacerda/storage/dovecot.map.index

2017-08-18T11:46:12.764926940Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com):
Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage:
rebuilding indexes


Regards,

Webert Lima
DevOps Engineer at MAV Tecnologia
*Belo Horizonte - Brasil*

Re: dotlock causing crashes

[Aki Tuomi]

On 16.08.2017 21:17, Ian Bobbitt wrote:
> OS: CentOS 7 x86_64
> Dovecot version: 2.2.31 (65cde28) (GhettoForge RPM)
> Filesystem: GlusterFS, but working on changing that. Only one server is 
> receiving activity.
>
> Was getting messages about corrupt dovecot.map.index files. Changed to 
> dotlock from fcntl to try to fix that.
>
> Reading symbols from /usr/libexec/dovecot/imap...(no debugging symbols 
> found)...done.
> [New LWP 74012]
> Core was generated by `dovecot/imap'.
> Program terminated with signal 6, Aborted.
> #0  0x7fa262c741d7 in __GI_raise (sig=sig@entry=6) at 
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> 56  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> (gdb) bt full
> #0  0x7fa262c741d7 in __GI_raise (sig=sig@entry=6) at 
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> resultvar = 0
> pid = 74012
> selftid = 74012
> #1  0x7fa262c758c8 in __GI_abort () at abort.c:90
> save_stage = 2
> act = {__sigaction_handler = {sa_handler = 0x7ffd7009f401, 
> sa_sigaction = 0x7ffd7009f401}, sa_mask = {__val =
> {0, 0, 140335431377968, 140335423109592, 140335422613219, 4246482, 
> 140335418575669, 12278048, 4192326493288016896,
> 12278592, 140335423192931, 0, 0, 140335425698848, 12280232, 
> 140726483153732}}, sa_flags = 1657305400, sa_restorer = 0x79a}
> sigs = {__val = {32, 0 }}
> #2  0x7fa26309eac6 in default_fatal_finish (type=, 
> status=status@entry=0) at failures.c:201
> backtrace = 0xbb5958 "/usr/lib64/dovecot/libdovecot.so.0(+0x9eace) 
> [0x7fa26309eace] ->
> /usr/lib64/dovecot/libdovecot.so.0(+0x9ebae) [0x7fa26309ebae] -> 
> /usr/lib64/dovecot/libdovecot.so.0(i_fatal+0)
> [0x7fa26303012c] -> /usr"...
> #3  0x7fa26309ebae in i_internal_fatal_handler (ctx=0x7ffd7009f4d0, 
> format=, args=) at
> failures.c:670
> status = 0
> #4  0x7fa26303012c in i_panic (format=format@entry=0x7fa2630d11de "file 
> %s: line %d: unreached") at failures.c:275
> ctx = {type = LOG_TYPE_PANIC, exit_status = 0, timestamp = 0x0, 
> timestamp_usecs = 0}
> args = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 
> 0x7ffd7009f5d0, reg_save_area = 0x7ffd7009f510}}
> #5  0x7fa2630a344f in file_lock_do (fd=fd@entry=20, 
> path=path@entry=0xbb5868
> "/gnoc/mail/home/bgeels/mail/mailboxes/Junk/dbox-Mails/.vsize.lock23f657caa43d8796",
>  lock_type=lock_type@entry=1,
> lock_method=lock_method@entry=FILE_LOCK_METHOD_DOTLOCK, timeout_secs=0, 
> error_r=error_r@entry=0x7ffd7009f768) at
> file-lock.c:285
> lock_type_str = 0x7fa2630e6948 "write-lock"
> started = 1502905468
> ret = 
> __FUNCTION__ = "file_lock_do"
> #6  0x7fa2630a3796 in file_wait_lock_error (fd=20, path=0xbb5868
> "/gnoc/mail/home/bgeels/mail/mailboxes/Junk/dbox-Mails/.vsize.lock23f657caa43d8796",
>  lock_type=1,
> lock_method=FILE_LOCK_METHOD_DOTLOCK, timeout_secs=, 
> lock_r=0xc4ec10, error_r=0x7ffd7009f768) at
> file-lock.c:314
> ret = 
> #7  0x7fa2630a3813 in file_try_lock_error (fd=, 
> path=, lock_type=lock_type@entry=1,
> lock_method=lock_method@entry=FILE_LOCK_METHOD_DOTLOCK, 
> lock_r=lock_r@entry=0xc4ec10,
> error_r=error_r@entry=0x7ffd7009f768) at file-lock.c:66
> No locals.
> #8  0x7fa2630a0955 in try_create_new (error_r=0x7ffd7009f768, 
> lock_r=0xc4ec10, fd_r=0x7ffd7009f700,
> set=0x7ffd7009f770, path=0xc2f930 
> "/gnoc/mail/home/bgeels/mail/mailboxes/Junk/dbox-Mails/.vsize.lock") at
> file-create-locked.c:65
> fd = 20
> orig_errno = 
> ret = -1
> temp_path = 0xbb5830
> mode = 0
> uid = 
> gid = 4294967295
> #9  file_create_locked (path=0xc2f930 
> "/gnoc/mail/home/bgeels/mail/mailboxes/Junk/dbox-Mails/.vsize.lock",
> set=set@entry=0x7ffd7009f770, lock_r=lock_r@entry=0xc4ec10, 
> created_r=created_r@entry=0x7ffd7009f767,
> error_r=error_r@entry=0x7ffd7009f768) at file-create-locked.c:118
> i = 0
> fd = 
> ret = 
> __FUNCTION__ = "file_create_locked"
> #10 0x7fa2633e8f80 in vsize_update_lock_full (update=0xc4ebd0, 
> lock_secs=lock_secs@entry=0) at index-mailbox-size.c:150
> box = 0xc2e268
> perm = 0xc2e440
> set = {lock_timeout_secs = 0, lock_method = FILE_LOCK_METHOD_DOTLOCK, 
> mode = 384, uid = 0, gid = 4294967295,
> gid_origin = 0xc2ea58 "/gnoc/mail/home/bgeels/mail/mailboxes/Junk"}
> error = 0x7fa2633f2062  
> "1\300[]A\\\303\017\037\200"
> created = false
> #11 0x7fa2633e9057 in index_mailbox_vsize_update_try_lock 
> (update=) at index-mailbox-size.c:167
> No locals.
> #12 0x7fa2633e9755 in index_mailbox_vsize_update_appends (box= out>) at index-mailbox-size.c:479
> update = 0xc4ebd0
> status = {messages = 1323, recent = 0, unseen = 0, uidvalidity = 
> 1413091786, uidnext = 6750, first_unseen_seq =
> 0, first_recent_uid = 5886, last_cached_seq = 0, highest_modseq = 0, 
> highest_pvt_modseq 

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

[Ralph Seichter]

On 18.08.2017 09:12, voy...@sbt.net.au wrote:

> for a public web server where https is becoming mandatory, I'd still
> need a certificate from a recognized publisher, to avoid users geting
> 'warnings', is that so ?

For a certificate to be reported as "valid", an unbroken chain of
cryptographic signatures is required. Browsers are released with a set
of Root CA and Intermediate CA certificates, as are operating systems.
Some use the Mozilla CA Certificate Store[1], for example, others come
with their own CA stores, like macOS[2].

[1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
[2] https://support.apple.com/en-us/HT202858

Unless your web server certificate's signature chain originates from one
of the CAs delivered with a web browser or OS, the end user connecting
to your site will either have to manually add the required CAs, or add
your server certificate, or be presented with a warning/error message.

One could argue that relying on certificate stores is placing personal
security concerns in other people's hands. Of course, it would be a
potentially funny thing to try and verify the validity of your online
banking server's certificate by asking them to send you a letter
containing the certificate fingerprint...

-Ralph

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

[Ralph Seichter]

On 18.08.2017 08:58, Michael Felt wrote:

> as Ralph mentions in his reply - Let's encrypt certs are only for
> three months - never ending circus.

I don't consider the 90-day-lifespan a "circus". It is meant as a
security feature[1], and Let's Encrypt suggests using automation for
certificate renewal. Also, with ACME v2 on the horizon[2], I imagine
that more automation tools will become available.

[1] https://letsencrypt.org/2015/11/09/why-90-days.html
[2] https://letsencrypt.org/2017/06/14/acme-v2-api.html

Let's not forget that Let's Encrypt is still a young service, and that
it is free.

-Ralph

Re: Dovecot mail_location for fedora

[Noel Butler]

Ahh thats it :) 

He should be good now, no idea why a fedora install wouldn't have that 

On 18/08/2017 19:43, Aki Tuomi wrote:

> mail_location=~/.mail:INBOX=/var/spool/mail/%Ln
> 
> Aki

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature

Re: Dovecot mail_location for fedora

[Aki Tuomi]

mail_location=~/.mail:INBOX=/var/spool/mail/%Ln

Aki

On 18.08.2017 12:41, Noel Butler wrote:
> On 18/08/2017 06:15, Randy Gordey wrote:
>
>> What is the syntax for dovecot mail_location when postfix delivers mail to
>> /var/spool/mail/?
>>
>> These are the old unix style mbox, one file per user.
>>
>> Not setting mail_location in 10-mail.conf results in Auto not finding it.
>>
>> mbox: /var/spool/mail/%u said mbox root directory can't be a file.
> Its been over 10 years since I've run mbox, but i'm sure your format is
> wrong, you're also not supposed to use spaces either, in fact I think
> its telling you whats wrong, from memory, its mbox:~/mail: 
> but I cant recall what otherstuff is I know the pathis in it but it
> needs something before it, I just cant recall what, see the wiki, I'd be
> highly surprised if it did not explain it. 
>
>> mbox: /var/spool/mail/ tries to make Sent and Deleted Folders, etc.
>>
>> maildir: /var/spool/mail/ closes the connection.
> Thats not how maildir works you need to add the Maildir directory to it,
> ie  maildir:/var/spool/mail/%n/Maildir 
>
> but DO NOT USE THAT directory!  And its more than dovecot you need to
> change if you're going to use maildir, so just fix up your mbox
> settings. 
>

Re: Dovecot mail_location for fedora

[Noel Butler]

On 18/08/2017 06:15, Randy Gordey wrote:

> What is the syntax for dovecot mail_location when postfix delivers mail to
> /var/spool/mail/?
> 
> These are the old unix style mbox, one file per user.
> 
> Not setting mail_location in 10-mail.conf results in Auto not finding it.
> 
> mbox: /var/spool/mail/%u said mbox root directory can't be a file.

Its been over 10 years since I've run mbox, but i'm sure your format is
wrong, you're also not supposed to use spaces either, in fact I think
its telling you whats wrong, from memory, its mbox:~/mail: 
but I cant recall what otherstuff is I know the pathis in it but it
needs something before it, I just cant recall what, see the wiki, I'd be
highly surprised if it did not explain it. 

> mbox: /var/spool/mail/ tries to make Sent and Deleted Folders, etc.
> 
> maildir: /var/spool/mail/ closes the connection.

Thats not how maildir works you need to add the Maildir directory to it,
ie  maildir:/var/spool/mail/%n/Maildir 

but DO NOT USE THAT directory!  And its more than dovecot you need to
change if you're going to use maildir, so just fix up your mbox
settings. 

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature

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

[Noel Butler]

On 18/08/2017 17:12, voy...@sbt.net.au wrote:

> BUT, for a public web server where https is becoming mandatory, I'd still
> need a certificate from a recognized publisher, to avoid users geting
> 'warnings', is that so ?
> 
> (I'm currently using self issued for both mail and web)
> 
> thanks,
> 
> V

It depends on what you're uses are, self signed certs are OK for
smtp/pop3/imap, since most people are just concerned with "encryption"
in that case, but a different story if its web content, in particular,
shopping carts and the like, If you have clients content, definitely use
a real cert, maybe in 10 years letsencrypt might make the grade, but
until every bit of software and OS supports it and they offer insurance
levels like the bi boys do, you might as well be using a self signed
cert,  comodo are pretty cheap with basic insurance level on even the
most basic of their offerings. Do your research, though if using a paid
service, since some others are soon to be un-trusted. 

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature

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

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


I'm not sure how you have set up your clustered service, but why do
your nodes have to go offline?  If these other nodes are using an older
certificate, it should still work as the previous/renewed certificate
usually have overlapping active begin/expiration dates.

Joseph Tam 

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

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 18 Aug 2017, voy...@sbt.net.au wrote:


BUT, for a public web server where https is becoming mandatory, I'd still
need a certificate from a recognized publisher, to avoid users geting
'warnings', is that so ?


As Michael wrote already, it's the same vor all SSL certificates, because 
the underlying mechanism is the same.


- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEVAwUBWZakenz1H7kL/d9rAQLV7ggAqgiz+7ttcsu4/JAHExarvu+aovhNk+Lp
OqzdlME8tSnEzKUfeHmkgXR2AMAOiET4HvsU0HWsm9zwyZ24Lgxo+mJ2lN6317H2
/nlNuQDImgDB8BLTarUpucVpp7R2ppXeuy+8TPyAmagZo6kR8okkFHoMzQSDHleG
gPjoBDVHq0FH6WYq25u2ts7l6L+FKEinX5T/b2hcIqnTgM129E/ak1gYZWmQm9+S
bM29aHNnpV/B8uPhACXruTV3DFWW2s9wIgopgHKA0XH4g7p3DYeiXFUTyZ+e9kNN
oabc56sQSd4QASpEBjsOPd8Sx3pZtiXzxZnb3yLIhjyCilwNLZA8xw==
=Phs1
-END PGP SIGNATURE-

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?

[Michael Felt]

On 8/18/2017 9:12 AM, voy...@sbt.net.au wrote:

On Fri, August 18, 2017 5:02 pm, Michael Felt wrote:

On 8/11/2017 1:29 PM, Ralph Seichter wrote:

And, Ralph, I salute you. I have never been able to be disciplined
enough to be my own CA.

I encourage you to look into the subject again.


I actually have been, which is why I could give a near sensible reply.
Thanks for the encouragement!


With the advent of Let's
Encrypt, free certs for the masses have become a thing, but if you need
more than 3 months validity, want to create certs for Intranet-devices
(routers, local servers), or just want maximum control over all certs,
setting up your own CA is rewarding. While you're at it, no gentleman
should not be without DNSSEC, DKIM and DANE these days. ;-)

I should know all three, but, sadly, only one: two things to add to my
list of things to research.


I have been reading this with some interest (while trying to migrate
Dovecot, Postfix etc..)

BUT, for a public web server where https is becoming mandatory, I'd still
need a certificate from a recognized publisher, to avoid users geting
'warnings', is that so ?

(I'm currently using self issued for both mail and web)

Above - Ralph added:

I also made my CA
certs available for public download, so tech-savvy users can import the
CA certs manually.
Depending on your site-popularity (aka number of "random" users) you 
could also instruct them how to access your signing key. Once they had 
that, they would auto-magically, recognize any other keys you signed 
with your CA "roots".


In other words, if the work to you to instruct users to use your CA is 
more expensive than using a commercial CA - save money and use a 
commercial CA. Before spending any money on a commercial CA - look at 
alternatives such as Let's Encrypt. I am also looking at 
http://www.cacert.org/ (That might be something for you Ralph!)




thanks,

V

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

[Joseph Tam]

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 

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

[voytek]

On Fri, August 18, 2017 5:02 pm, Michael Felt wrote:
> On 8/11/2017 1:29 PM, Ralph Seichter wrote:

>>> And, Ralph, I salute you. I have never been able to be disciplined
>>> enough to be my own CA.
>> I encourage you to look into the subject again.
>>
> I actually have been, which is why I could give a near sensible reply.
> Thanks for the encouragement!
>
>> With the advent of Let's
>> Encrypt, free certs for the masses have become a thing, but if you need
>> more than 3 months validity, want to create certs for Intranet-devices
>> (routers, local servers), or just want maximum control over all certs,
>> setting up your own CA is rewarding. While you're at it, no gentleman
>> should not be without DNSSEC, DKIM and DANE these days. ;-)
> I should know all three, but, sadly, only one: two things to add to my
> list of things to research.


I have been reading this with some interest (while trying to migrate
Dovecot, Postfix etc..)

BUT, for a public web server where https is becoming mandatory, I'd still
need a certificate from a recognized publisher, to avoid users geting
'warnings', is that so ?

(I'm currently using self issued for both mail and web)

thanks,

V

Re: /var/run/dovecot permission issues

[Alexander Moisseev]

On 8/17/2017 7:07 PM, Larry Rosenman wrote:

In /usr/local/etc/dovecot/conf.d/90-plugin.conf:



It should be enough to just set permissions as other options are defaults.

/usr/local/etc/dovecot/conf.d/10-master.conf :

service stats {
  fifo_listener stats-mail {
mode = 0666
  }
  fifo_listener stats-user {
mode = 0666
  }
  unix_listener stats {
mode = 0666
  }
}

BTW I'm not sure if write permissions on 'stats-user' and 'stats' listeners are 
required for metrics service.
At least I have no evidence if Dovecot ever tried to write to that listeners.
Probably it is enough to set write permissions on 'stats-mail'.

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

[Michael Felt]

On 8/11/2017 1:29 PM, Ralph Seichter wrote:

On 11.08.2017 11:36, Michael Felt wrote:


This is what Ralph means when he says "have been running a CA for
15+ years" - not that he is (though he could!) sell certificates
commercially - rather, he is using an initial certificate to sign
later certificates with.

Actually, I do sell certificates to my customers. :-) In small numbers,
and only for servers to which I have administrative access.

So, not really "selling", but an additional service.

I created a
root CA and two intermediate CAs (one each for client and server certs,
respectively).

It would be great to have my CAs added to Mozilla's NSS root certificate
store, but alas, the effort to get there is massive. Where possible, I
will add my CA certs to the customers' keystores. I also made my CA
certs available for public download, so tech-savvy users can import the
CA certs manually.


Again, technically, there is no difference in a self-signed 2048-bit RSA
key, and one signed by a "major" CA. However, in the "ease of use" there
may be major differences.

In 2015 I rolled out an updated CA which I have used ever since, with
4096 bit keys for root and intermediary CA certs. I also only generate
4096 bit keys for servers these days, so my cert chain is "stronger"
than those of some commercial CAs. Also, it is good to know that these
certs have never been touched by anybody but myself. I even install my
own CA cert chain on my iOS devices.


And, Ralph, I salute you. I have never been able to be disciplined
enough to be my own CA.

I encourage you to look into the subject again.
I actually have been, which is why I could give a near sensible reply. 
Thanks for the encouragement!

With the advent of Let's
Encrypt, free certs for the masses have become a thing, but if you need
more than 3 months validity, want to create certs for Intranet-devices
(routers, local servers), or just want maximum control over all certs,
setting up your own CA is rewarding. While you're at it, no gentleman
should not be without DNSSEC, DKIM and DANE these days. ;-)
I should know all three, but, sadly, only one: two things to add to my 
list of things to research.

-Ralph

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

[Michael Felt]

On 8/11/2017 11:44 AM, Florian Beer wrote:

On 2017-08-11 11:36, Michael Felt wrote:

I have looked at let's encrypt. Key issue for me is having to add a
lot python stuff that would otherwise not be on any server.



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.

Re: v2.2.32 release candidate released

[Timo Sirainen]

On 18 Aug 2017, at 2.25, Joseph Tam  wrote:
> 
>> a CREATE noselectbox/
>> --> With this change it's the same as CREATE "noselectbox" = will become 
>> selectable.
>> 
>> or
>> 
>> a CREATE noselectbox/childbox
>> b DELETE noselectbox/childbox
>> --> noselectbox is left behind. With this change it will be auto-deleted.
> 
> So, does that mean empty folders will be auto-deleted, or this wouldn't
> affect them?

Selectable folders won't be auto-deleted, only \NoSelect folders that have no 
child folders.

This auto-deletion is also done if LIST notices them. Actually the main reason 
it was implemented now was because with NFS if a folder is open while it's 
deleted, it could leave .nfs* files in the directory and prevent finishing the 
deletion. So a folder deletion would change it into a \NoSelect folder, but not 
delete it entirely. This is mainly a user-visible problem if the new ITERINDEX 
feature is used.