Re: [FTS Xapian] RC release

[Marcus Rückert]

On Thu, 24 Jan 2019 14:35:13 +0100
Joan Moreau via dovecot  wrote:

> Hi, 
> 
> FTS Xapian matches my targets for the plugins (replacing deprecated
> fts-squat in a production environment) 
> 
> https://github.com/grosjo/fts-xapian 
> 
> Please do not hesitate to add "issues" on github, if the case happen 

created a ticket with all the issues I found while trying to package it
for openSUSE.

-- 
  openSUSE - SUSE Linux is my linux
  openSUSE is good for you
  www.opensuse.org

Re: Read the quota_exceeded_message from a file

[Marcus Rückert]

On Thu, 25 Oct 2018 07:25:33 +0200
Alexander Dalloz  wrote:
> That's not surprising as for systemd controlled services the tmp is
> not /tmp but a private tmp inside /var/tmp/systemd-private*

This is not generally true but depends on the service file and the
options used there.



-- 
  openSUSE - SUSE Linux is my linux
  openSUSE is good for you
  www.opensuse.org

Re: Struggling to get dovecot working with postfix auth

[Marcus Rückert]

IF you see apparmor problems or suspect it might be an apparmor issue:

1. run auditd
2. check /var/log/audit/audit.log

for this specific case. those socket paths are allowed for dovecot:

/var/spool/postfix/private/auth
/var/spool/postfix/private/dovecot-auth
/var/spool/postfix/private/dovecot-lmtp

hth

   darix

-- 
  openSUSE - SUSE Linux is my linux
  openSUSE is good for you
  www.opensuse.org

Re: Disabling index files?

[Marcus Rückert]

On Tue, 5 Dec 2017 11:53:45 +
Stroller  wrote:

> The wiki says:
> 
> > Each mailbox has its own separate index files. **If the index files
> > are disabled**, the same structures are still kept in the memory,
> > except cache file is disabled completely (because the client
> > probably won't fetch the same data twice within a connection). [1]  
> 
> I tend to grep my maildirs quite often, and use the output to cp
> emails to other folders, so it's annoying when the
> dovecot.index.cache files show up in the results.
> 
> How do I disable the index files, please? 
> 
> My mail server is hardly loaded, so I don't think it'll be a problem
> to keep the caching in memory.
> 
> I can find `mailbox_list_index = no`
> in /etc/dovecot/conf.d/10-mail.conf but this seems to be enabled by
> default, and it makes no difference when I enable it explicitly -
> deleted dovecot.index.cache are recreated when Dovecot is restarted.
> The setting `mbox_min_index_size` tends to suggests it's only for
> mbox files, not maildirs?
> 
> Thanks in advance for any help you can offer,

hint: try server side search with your imap client. for me it beats
grep easily. Personally I just use the clucene based FTS and it
searches even mailboxes with 300-500k mails within single digit seconds.

   darix

-- 
  openSUSE - SUSE Linux is my linux
  openSUSE is good for you
  www.opensuse.org

Timing information for passdb/userdb lookups

[Marcus Rückert]

Hi,

it would be nice to have an option to enable logging for timings
without having to go with auth_verbose/auth_debug. If you try to track
down if a slowdown for logging in comes from e.g. running out of login
workers or if your auth backend is slow it would really help to get
just a one line message per userdb/passdb with the timing for this
lookup.

something like:

imap-login(): userdb ldap lookup time 0.4s
imap-login(): passdb ldap lookup time 0.2s

or even merging into one:

imap-login(): userdb ldap lookup time 0.4s passdb ldap lookup time 
0.2s

darix

-- 
  openSUSE - SUSE Linux is my linux
  openSUSE is good for you
  www.opensuse.org

Re: need help debugging deleted mails

[Marcus Rückert]

mail_log plugin might help


darix


-- 
  openSUSE - SUSE Linux is my linux
  openSUSE is good for you
  www.opensuse.org

Re: Deafness

[Marcus Rückert]

On Wed, 29 Jul 2015 08:12:26 -0700
alvin alvin...@mail.linux-consulting.com wrote:

 
 hi ya
 
 On Tue, Jul 28, 2015 at 11:35:31PM -0400, Chris Ross wrote:
  
   On Jul 28, 2015, at 21:52 , Steffan Cline stef...@hldns.com
   wrote:
   
   Ok, I think I have come a little further.
   
   When dovecot stops accepting connections, I checked netstat and
   found this:
   
   [root@hosting1 ~]#  netstat -an | grep 993
   tcp0  0 0.0.0.0:993
   0.0.0.0:*   LISTEN tcp0  0
   65.39.x.x:993184.101.x.x:36351SYN_RECV
   tcp0  0 65.39.x.x:993
   107.212.x.x:51487SYN_RECV tcp0  0
   65.39.x.x:993107.212.x.x:51488SYN_RECV
   tcp0  0 65.39.x.x:993
   184.101.x.x:44650SYN_RECV

Are all the users with problems behind NAT e.g?

https://www.youtube.com/watch?v=gfYYggNkM20

-- 
  openSUSE - SUSE Linux is my linux
  openSUSE is good for you
  www.opensuse.org

Re: Best practices for mailbox network file storage?

[Marcus Rückert]

On Tue, 16 Jun 2015 19:24:12 +
Andy Csillag a...@thecsillags.com wrote:

 Is there a current best practice for a shared filesystem backend for
 mailboxes (in my case, all virtual accounts)?  NFS 3/4, GFS2,
 GlusterFS, other?  In the case of the latter ones, is the use of
 Director necessary?  Any specific anti-recommendations?  Also, if it
 matters, I *think* I want to use BackBlaze racks for storage.  Also,
 I've seen recommendations for the filesystem underneath like XFS or
 ext4 or whatever.  Is there a best practice?
 
 Thanks,
 Drew

http://wiki2.dovecot.org/NFS

-- 
  openSUSE - SUSE Linux is my linux
  openSUSE is good for you
  www.opensuse.org

Re: /etc/ssl/certs/dovecot.pem erased by OpenSuse's update mechanism

[Marcus Rückert]

On Mon, 16 Feb 2015 10:09:16 +0100
Wolfgang Gross wgr...@uni-hd.de wrote:

 Hi,
 
 this is not a genuine Dovecot bug, more a nuisance.
 It applies to OpenSuse 13.2 but maybe also to other Linux's.
 
 The standard installation of Dovecot (especially 10-ssl.conf) places
 the certificate dovecot.pem in /etc/ssl/certs.
 Sometimes during updates does OpenSuse renew all certificates
 in /etc/ssl/certs and erases dovecot.pem. This blocks further access
 to the mailbox.
 
 I found a similar report here:
   https://bbs.archlinux.de/viewtopic.php?id=27288
 
 Workaround: Move dovecot.pem to another directory and change
 10-ssl.conf accordingly.

This is *not* our update mechanism. This is update-ca-certificates,
which will wipe /etc/ssl/certs/ when it is called. This can happen to
you on any distro using it. My recommendation is to
use /etc/ssl/private/ for all service related files. Certs and keys.

HTH

darix

-- 
  openSUSE - SUSE Linux is my linux
  openSUSE is good for you
  www.opensuse.org