headers
Timo Sirainen | 1 Jun 2012 12:26
Picon
Picon
Favicon

Re: inet_listener imaps { port = 0 } question

On 31.5.2012, at 16.58, henrixd wrote:

> Why commenting out "inet_listener imaps {}" won't stop dovecot to listen port 993? I think this would be
expected behavior. Just curious, finally got it working with port = 0. :)

When you comment out something, Dovecot uses the default settings for it. By default Dovecot listens on
port 993.
Permalink | Reply | 0 comments |
headers
Joe Beaubien | 1 Jun 2012 17:36
Picon

Inconsistent search results and crash on force-resync

Hi,

I am seeing inconsistencies in search results (finding 2 emails when only 1
exists, finding the email when it has been moved to another folder, etc).

I figured I should run force-resync to fix any issues. I ran the following:
doveadm -v force-resync -u <user> <mailbox> and I got some worrysome logs.
  - I should mention that I have been seeing some crashes of fts-lucene in
my logs. I sent a traceback of this on the mailing list 1-2 days ago under
the subject "[Dovecot] fts_lucene crashing".
  - I should also mention that all the problems I am having are only in 1
email account. This email account contains folders of over 100k emails. Do
I need to tweak dovecot somehow for this? Up until now all I did was change
vsz_limit to 1024 MB for "service imap".

Here are the logs:

Jun  1 11:15:01 XXXXX dovecot: imap(form): Error: Recent flags state
corrupted for mailbox INBOX2
Jun  1 11:15:01 XXXXX dovecot: imap(form): Error:
/data/emails/form/mailboxes/INBOX2/dbox-Mails/dovecot.index reset, view is
now inconsistent
Jun  1 11:15:01 XXXXX dovecot: imap(form): Error:
/data/emails/form/mailboxes/INBOX2/dbox-Mails/dovecot.index reset, view is
now inconsistent
Jun  1 11:15:01 XXXXX dovecot: imap(form): Error: Recent flags state
corrupted for mailbox contrat
Jun  1 11:15:01 XXXXX dovecot: imap(form): Error:
/data/emails/form/mailboxes/contrat/dbox-Mails/dovecot.index reset, view is
now inconsistent
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthijs Kooijman | 1 Jun 2012 20:27
Picon

Exposing global (default) sieve script through Managesieve

Hi folks,

I'm setting up a dovecot server with managesieve support. I'd like to
offer spamfiltering through a Sieve script to my users by default,
but still allow them to modify the filtering rules through Managesieve.

I found the sieve_global_path configuration option, which seems perfect
for what I want. I can configure a default script there, which will work
for all users until they set upload their own sieve script using
managesieve.

However, when configured like this, the user experience isn't quite
perfect. When users open the managesieve interface on their client,
there is no trace of the default filters, so users might think the
spamfiltering is done in some other manner. Now, when they create a
filtering rule (e.g., to sort out mail to mailing lists), that rule will
overwrite the default spamfiltering rule causing all the spam to spill
into the user's mailbox. I'm afraid that most users won't realize they
have to manually recreate the spamfiltering rule to fix this. Also, they
might not know how to write the rule, even if they do...

I've considered a few existing ways to fix this:
 - Use sieve_before / sieve_after to make sure that the default script
   is always executed, in addition to any user-supplied scripts. This
   removes the surprise, but removes the option for users to tweak the
   spamfiltering rules.
 - Don't use sieve_global_path, but instead distribute the default
   script to each user's homedir on user creation. This prevents making
   changes to the default script for existing users and in my setup,
   user creation and (mail)homedir creation are nicely separated through
(Continue reading)

Permalink | Reply | 3 comments |
headers
Patrick Ben Koetter | 1 Jun 2012 22:58
Picon

dovecot stats: useful data to gather

Timo,

following our discussion on dovecot stats at the LinuxTag 2012 my team and I
sat down and put together a list of stat items we think to be useful in daily
dovecot usage.

Besides pulling together all the data we also think it would be useful to have
an SNMP interface to access the stats. Our offer to create and contribute a
standalone web interface for dovecot stats stands.

Here are the stats we believe to be useful:

Login/Logout
- total number login success/time
- total number login failure/time
- total number per authentication mechanism
- total number plain sessions
- total number STARTTLS sessions
- total number of currently connected users (pop3/pop3s/imap/imaps/managesieve)
- login names of connected users (not really stats, but great for actions
  regarding those uses e.g. force logout)
- total number logout commands/time
- total number BYE responses (autologout)

Mailbox state
- Inflow rate (number incoming messages/time)
- Deleted rate (number \Deleted flagged messages/time)
- Expunge rate (number Expunge operations/time)
- total number current messages mailboxes normal storage
- total number current messages mailboxes alt storage
(Continue reading)

Permalink | Reply | 5 comments |
headers
Glenn English | 1 Jun 2012 22:26

auth trouble

Debian Lenny, Dovecot v 1.0.15.

I'm getting a lot of what I think is a local socket asking 
dovecot:auth to verify username/passwords:

> May 31 09:00:54 server dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname=
uid=0 euid=0 tty=dovecot ruser=admin rhost= 

Note the empty 'rhost='. That's why I think it's on the 
server. I see others that look like bots:

> May 30 23:08:43 server dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname=
uid=0 euid=0 tty=dovecot ruser=admin rhost=200.119.139.22 

And I know how to promote the latter to a firewall. But with no 
rhost, I'm stumped...

I've read books, googled, read docs, and asked for help on 
other mailing lists, and I've learned a lot. And I no longer 
think it really has much to do with Dovecot, other than the 
login attempt going through it to get to PAM.

But has anyone here seen this before? Is my current theory 
correct? What did you do to make it go away?

(I suspect that upgrading to Debian Squeeze might get rid of 
it, but I'm afraid that if I don't figure out what's going 
on, it might just come back.)

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Timo Sirainen | 2 Jun 2012 00:15
Picon
Picon
Favicon

Re: dovecot stats: useful data to gather

On 1.6.2012, at 23.58, Patrick Ben Koetter wrote:

> Besides pulling together all the data we also think it would be useful to have
> an SNMP interface to access the stats.

I had thought about SNMP before also, but for the current kind of stats that are exported I couldn't think of
any reasonable way to export them.

> Here are the stats we believe to be useful:
> 
> Login/Logout
> - total number login success/time
> - total number login failure/time
..

I'll look at these later in more detail, but some important questions / design decisions:

Currently stats process only remembers things after Dovecot was started. I don't think getting these kind
of numbers would really work like that. Perhaps all of the statistics should be permanently dumped to disk
every ~minute or so + at shutdown and loaded at startup, so the numbers would at least normally always just
increase since the first time Dovecot was started?

> Mailbox state
> - Inflow rate (number incoming messages/time)
> - Deleted rate (number \Deleted flagged messages/time)

These operations/time type of things I had hoped to be able to externalize :) If stats process simply gives
the raw stats, the reader could do this kind of summing up. Otherwise .. well, I guess it could maybe keep
track of the current ops/<last 60 secs> and the reader would then have to read the value about once a minute
or half or something. It wouldn't give exact results though.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Glenn English | 2 Jun 2012 00:23

Re: auth trouble

I forgot to include this config info:

> # 1.0.15: /etc/dovecot/dovecot.conf
> log_timestamp: %Y-%m-%d %H:%M:%S 
> protocols: imap pop3
> ssl_listen: *
> ssl_disable: yes
> disable_plaintext_auth: no
> login_dir: /var/run/dovecot/login
> login_executable(default): /usr/lib/dovecot/imap-login
> login_executable(imap): /usr/lib/dovecot/imap-login
> login_executable(pop3): /usr/lib/dovecot/pop3-login
> login_max_processes_count: 12
> mail_privileged_group: mail
> mail_executable(default): /usr/lib/dovecot/imap
> mail_executable(imap): /usr/lib/dovecot/imap
> mail_executable(pop3): /usr/lib/dovecot/pop3
> mail_plugin_dir(default): /usr/lib/dovecot/modules/imap
> mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap
> mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3
> pop3_uidl_format(default): 
> pop3_uidl_format(imap): 
> pop3_uidl_format(pop3): %08Xu%08Xv
> auth default:
>   mechanisms: plain login
>   verbose: yes
>   passdb:
>     driver: pam
>   userdb:
>     driver: passwd
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Ben Koetter | 2 Jun 2012 06:57
Picon

Re: dovecot stats: useful data to gather

* Timo Sirainen <dovecot <at> dovecot.org>:
> On 1.6.2012, at 23.58, Patrick Ben Koetter wrote:
> 
> > Besides pulling together all the data we also think it would be useful to have
> > an SNMP interface to access the stats.
> 
> I had thought about SNMP before also, but for the current kind of stats that
> are exported I couldn't think of any reasonable way to export them.

I am not an expert on SNMP, others in my office are, but as I understand it
there's no need for Dovecot to export the data. AFAIK Dovecot would have to
offer a subagent, which could be queried by a SNMP server.

If we need more knowledge on SNMP I can ask my folks on the team to give some
guidance. For the moment I found this:
<http://net-snmp.sourceforge.net/wiki/index.php/TUT:Writing_a_Subagent>

> > Here are the stats we believe to be useful:
> > 
> > Login/Logout
> > - total number login success/time
> > - total number login failure/time
> ..
> 
> I'll look at these later in more detail, but some important questions / design decisions:
> 
> Currently stats process only remembers things after Dovecot was started. I
> don't think getting these kind of numbers would really work like that.
> Perhaps all of the statistics should be permanently dumped to disk every
> ~minute or so + at shutdown and loaded at startup, so the numbers would at
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ed W | 2 Jun 2012 11:20

Re: interesting stats pattern

On 29/05/2012 19:13, Timo Sirainen wrote:
> On 29.5.2012, at 21.03, Cor Bosman wrote:
>
>> es, I am getting a list of sessions/users every 5 minutes through cron. Im already using "doveadm stats
dump session/user connected"
> Actually that's not really correct behavior either, since it ignores all the connections that happened
during the 5 minutes if they don't exist at the time when you're asking for them. I'm not sure what the most
correct way to do this kind of a graph would be :)

I muttered about some ideas for enhanced login/logout tracking some 
months back.  Perhaps this would be another example of a motivation to 
use it for something?  Could either the login scripting or a plugin be 
used to build this type of login tracking?

(My goal is to eventually do per user "are you logged in" tracking)

Just a thought

Ed W
Permalink | Reply | 0 comments |
headers
Ed W | 2 Jun 2012 11:23

Re: Strange Dovecot 2.0.20 auth chokes and cores

On 30/05/2012 17:25, Alan Brown wrote:
>> Is any problem with epoll on 3.2.x kernels?
>
> Yes - and it's been discussed here.
>
> Some "bright spark" rewrote the kernel epoll code to prevent DoS 
> attacks caused by "excessive forking".
>

Do you have a link to the previous discussions?  This is new to me? 
Can't find it immediately in the list?

Cheers

Ed W
Permalink | Reply | 1 comment |

Gmane