Re: [Dovecot] occasional dovecot crash, core captured but no symbol table info?

[mail...@securitylabs.it]

Il 26/08/2011 20:38, John Clements ha scritto:

Dovecot is crashing occasionally for me.  Today it crashed six times in quick 
succession, as I fired up a computer (Mac) I hadn't used in a while, and my 
mail application (Apple Mail) tried to synchronize many large mailboxes.

The log entries look like this:

Aug 26 10:26:15 computer dovecot: dovecot: child 23223 (imap) killed with 
signal 6 (core dumped)
Aug 26 10:26:30 computer dovecot: IMAP(granitemon): Panic: file 
istream-raw-mbox.c: line 583 (istream_raw_mbox_get_body_size): assertion failed: 
(rstream->body_offset != (uoff_t)-1)


Hello,

http://www.dovecot.org/list/dovecot/2010-March/047426.html

dunno if it has been fixed in 1.2.16 or 1.2.17, you may try to upgrade 
to 1.2.17 or apply the above patch.

[Dovecot] occasional dovecot crash, core captured but no symbol table info?

[John Clements]

Dovecot is crashing occasionally for me.  Today it crashed six times in quick 
succession, as I fired up a computer (Mac) I hadn't used in a while, and my 
mail application (Apple Mail) tried to synchronize many large mailboxes.

The log entries look like this:

Aug 26 10:26:15 computer dovecot: dovecot: child 23223 (imap) killed with 
signal 6 (core dumped)
Aug 26 10:26:30 computer dovecot: IMAP(granitemon): Panic: file 
istream-raw-mbox.c: line 583 (istream_raw_mbox_get_body_size): assertion 
failed: (rstream->body_offset != (uoff_t)-1)
Aug 26 10:26:30 computer dovecot: IMAP(granitemon): Raw backtrace: imap() 
[0x80f0e1e] -> imap() [0x80f0e82] -> imap() [0x80f0809] -> 
imap(istream_raw_mbox_get_body_size+0x407) [0x8092f47] -> 
imap(istream_raw_mbox_next+0x25) [0x8093025] -> 
imap(istream_raw_mbox_seek+0x1f3) [0x8093323] -> imap(mbox_file_seek+0x55) 
[0x8093745] -> imap() [0x8095852] -> imap() [0x8095c8d] -> 
imap(index_mail_set_seq+0x153) [0x80a35c3] -> imap() [0x8095fb9] -> 
imap(index_storage_search_next_nonblock+0x13b) [0x80a763b] -> 
imap(mailbox_search_next_nonblock+0x2a) [0x80b5c1a] -> 
imap(mailbox_search_next+0x28) [0x80b5c68] -> imap(imap_fetch_more+0x274) 
[0x806a4c4] -> imap() [0x8062665] -> imap() [0x806753f] -> 
imap(client_output+0xeb) [0x806862b] -> imap() [0x810007e] -> 
imap(io_loop_handler_run+0xd6) [0x80f9aa6] -> imap(io_loop_run+0x20) 
[0x80f8f20] -> imap(main+0x5b4) [0x8070f24] -> 
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0xb75f3c76] -> imap() 
[0x80603a1]
Aug 26 10:26:30 computer dovecot: dovecot: child 23228 (imap) killed with 
signal 6 (core dumped)

Here's the output of dovecot -n:

clements@computer:/home/granitemon$ sudo dovecot -n
# 1.2.15: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-5-686 i686 Debian 6.0.2 
log_timestamp: %Y-%m-%d %H:%M:%S 
login_dir: /var/run/dovecot/login
login_executable: /usr/lib/dovecot/imap-login
mail_privileged_group: mail
mbox_write_locks: fcntl dotlock
lda:
  postmaster_address: postmas...@brinckerhoff.org
  mail_plugins: sieve
auth default:
  passdb:
driver: pam
  userdb:
driver: passwd

... this is the version associated with debian stable.

Finally, since I had coredumps enabled, I'm in a position to provide 'bt full', 
but it looks like my binaries are stripped, so I'm not getting source code line 
numbers.

granitemon@computer:~$ gdb /usr/lib/dovecot/imap ./core 
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/lib/dovecot/imap...(no debugging symbols 
found)...done.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/i686/cmov/libdl.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/cmov/libdl.so.2
Reading symbols from /usr/lib/libldap_r-2.4.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libldap_r-2.4.so.2
Reading symbols from /lib/i686/cmov/librt.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/cmov/librt.so.1
Reading symbols from /lib/i686/cmov/libc.so.6...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/liblber-2.4.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/liblber-2.4.so.2
Reading symbols from /lib/i686/cmov/libresolv.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/cmov/libresolv.so.2
Reading symbols from /usr/lib/libsasl2.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libsasl2.so.2
Reading symbols from /usr/lib/libgnutls.so.26...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libgnutls.so.26
Reading symbols from /lib/i686/cmov/libpthread.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/cmov/libpthread.so.0
Reading symbols from /usr/lib/libtasn1.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libtasn1.so.3
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libgcrypt.so.11...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libgcrypt.so.11
Reading symbols from /usr/lib/libgpg-error.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libgpg-error.so.0
Reading symbols from /lib/i686/cmov/libnss_compat.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/cmov/libnss_compat.so.2
Reading symbols from /lib/i686/cmo

Re: [Dovecot] limiting number of incorrect logins per connection

[a...@ahhyes.net]

Thanks for that. I will change it and recompile. Sorry for the grumpyness 
yesterday in my posts. Was having a bad day. Is there any chance of there being 
an option on future versions that allow a number of failed auth attempts to be 
specified before dropping the connection? The other thread you mentioned, I see 
someone devised a small patch in c to add this functionality. It didnt look 
like a lot of code to do it. What are your thoughts?

- Reply message -
From: "Timo Sirainen" 
Date: Sat, Aug 27, 2011 02:30
Subject: [Dovecot] limiting number of incorrect logins per connection
To: "Alex" 
Cc: 


login-common/client-common.h :

#define CLIENT_LOGIN_TIMEOUT_MSECS (MASTER_LOGIN_TIMEOUT_SECS*1000)

So set it to (45*60*1000)

But I don't think there's much of a practical difference between these.

On 26.8.2011, at 12.07, Alex wrote:

> 3 minutes! I think that's too long, how can I drop that down to about 45 
> seconds?
> 
> 
> On Fri, 26 Aug 2011 11:44:45 +0300, Timo Sirainen wrote:
>> On 26.8.2011, at 10.25, Alex wrote:
>> 
>>> Running Dovecot 2 on my server. It is regularly getting dictionary auth 
>>> attacked. What I have noticed is that once connected to a pop3/imap login 
>>> session, you can send endless incorrect usernames+passwords attempts. This 
>>> is a problem for me... I use fail2ban to try and stop these script kiddies. 
>>> The problem is that fail2ban detects the bad auths, firewalls the IP, 
>>> however, since it's an "established" session, the attacker can keep authing 
>>> away... It's only on a subsequent (new) connection that the firewalling 
>>> will take effect.
>> 
>> Umm. If client hasn't managed to log in in 3 minutes, it's
>> disconnected (no matter what it does with the connection).
> 

Re: [Dovecot] File Permissions and delivery

[Patrick Domack]

Just adding that won't make dovecot use it though, you would have to
include the postconf -n output. Normally something like
virtual_transport=dovecot


Quoting Simon Brereton :


On 26 August 2011 19:35, Patrick Domack  wrote:


My guess is your delivering email with postfix to the inbox,
instead of using dovecot-lda. And something odd is going on with
that postfix to get odd permissions like that.

You probably needed to edit the postfix virtual deliever transport,
or maybe you just forget to active the dovecot-lda (deliever)
transport.



That's why I included the portion from my master.cf


The portion of my master.cf
81 # SPB - Attempt to deliver with Dovecot LDA
 82 dovecot   unix  -   n   n   -   -   pipe
 83   flags=DRhu user=mailsystem argv=/usr/lib/dovecot/deliver -f
${sender} -d ${user}@${nexthop}

The numbers are just line numbers from vim.  The entry reads like:

# SPB - Attempt to deliver with Dovecot LDA
dovecot   unix  -   n   n   -   -   pipe
  flags=DRhu user=mailsystem argv=/usr/lib/dovecot/deliver -f
${sender} -d ${user}@${nexthop}

malsystem is the user and /usr/lib/dovecot/deliver exists.


Simon





Quoting Simon Brereton :


Hi

I'm very new to Dovecot (been using Courier for 5 years), but I've
been persuaded of the merits of Dovecot and since the server needs
upgrading that seems like the perfect time/excuse.

On a test server, I set up postfix and installed Dovecot (running
32-bit Debian Squeeze, installed from apt-get).  I mirrored the
mail store (Maildirs, for historical reasons located under
/var/spool/mail/virtual/domain.com/user).  Then I ran the courier 
migration perl script and everything was fine and dandy.


However, when I can to do the production migration, things weren't
as smooth.  The new server is 64-bit (not that I think it makes a 
difference, but if you're going to help me you should have all the

information :)

Again, I installed Postfix and Dovecot
Took down the old server
Mirrored the Maildirs
Ran the migration script
Restarted everything

At this point everything looked like it was ok.  Mail was being
received and delivered to the Maildirs and the IMAP login was
fine.  However, I noticed errors in the logs when retreiving mail 
with the MUA along the lines of:


Aug 26 16:59:48 mail dovecot: IMAP(si...@lydiard.net):
open(/var/spool/mail/virtual/domain.net/simon/cur/1314328966.V801I166601bM756462.mail.net,S=2461:2,)
 failed: Permission denied (euid=999(mailsystem) egid=115(mailsystem) missing 
+r perm:
/var/spool/mail/virtual/domain.net/simon/cur/1314328966.V801I166601bM756462.mail.net,S=2461:2,)

After messing around with the chown and chmod (even though these
were exactly the same as the test server) I finally discovered the
issue.

mail:~# ls /var/spool/mail/virtual/domain.net/simon/new/
-rwxrwx---  1 postfix mailsystem 2.5K Aug 26 03:33
1314326000.V801I1666018M803015.mail.net,S=2461:2,
-rwxrwx---  1 postfix mailsystem 2.5K Aug 26 03:36
1314326209.V801I1666019M447273.mail.net,S=2460:2,
-rw-rw  1 postfix mailsystem 2.5K Aug 26 04:00
1314327630.V801I166601aM308173.mail.net,S=2477:2,
-rw---  1 postfix mailsystem 2.5K Aug 26 04:22
1314328966.V801I166601bM756462.mail.net,S=2461:2,
-rw---  1 postfix mailsystem 1.1K Aug 26 16:28
1314372534.V801I166601cM615258.mail.net,S=1097:2,
-rw---  1 postfix mailsystem 1.1K Aug 26 16:31
1314372685.V801I166601dM264242.mail.net,S=1097:2,

Mails are being delivered with 0600 permissions and not 0660 (the
mails from courier seem to have all been 0770 as you can see).  If
I manually change the permission (to 0660) then I can see the mail
in the MUA.

After thinking for a while it occurred to me that this is covered
in the LDA section.  But making changes to the config file (either
permissions or UID/GID) doesn't seem to make a difference.  (Yes, 
I did restart postfix and dovecot after the changes).


Anyway, here is my dovecot -n:

mail:~# dovecot -n
# 1.2.15: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.2 ext3
log_timestamp: %Y-%m-%d %H:%M:%S
protocols: imap imaps pop3 pop3s
ssl_ca_file: /etc/ssl/keys/ca.crt
ssl_cert_file: /etc/ssl/keys/mail.net.crt
ssl_key_file: /etc/ssl/private/mail.net.key
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
mail_privileged_group: mailsystem
mail_location: maildir:/var/spool/mail/virtual/%d/%n
maildir_very_dirty_syncs: yes
mbox_write_locks: fcntl dotlock
mail_executable(default): /usr/lib/dovecot/imap
mail_executable(imap): /usr/lib/dovecot/imap
mail_executable(pop3): /usr/lib/dovecot/pop3
mail_plugins(default): quota imap_quota
mail_plugins(imap): quota imap_quota
mail_plugins(pop3): quota
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/

Re: [Dovecot] Catch22: user needs space to fix out of space condition

[Joseph Tam]

On Fri, 26 Aug 2011, Joseph Tam wrote:


Thanks to all who've made suggestions.  It seems removing dotlocks as
a locking method is the way to go.


Actually, this gives me pause that maybe I should not enirely remove
the dotlocking method


http://mailman2.u.washington.edu/pipermail/alpine-info/2008-July/000996.html

Any comments on the (sole) use of POSIX fcntl() type locking?

Joseph Tam 

Re: [Dovecot] File Permissions and delivery

[Simon Brereton]

On 26 August 2011 19:35, Patrick Domack  wrote:
>
> My guess is your delivering email with postfix to the inbox, instead of using 
> dovecot-lda. And something odd is going on with that postfix to get odd 
> permissions like that.
>
> You probably needed to edit the postfix virtual deliever transport, or maybe 
> you just forget to active the dovecot-lda (deliever) transport.


That's why I included the portion from my master.cf


The portion of my master.cf
81 # SPB - Attempt to deliver with Dovecot LDA
 82 dovecot   unix  -   n   n   -   -   pipe
 83   flags=DRhu user=mailsystem argv=/usr/lib/dovecot/deliver -f
${sender} -d ${user}@${nexthop}

The numbers are just line numbers from vim.  The entry reads like:

# SPB - Attempt to deliver with Dovecot LDA
dovecot   unix  -   n   n   -   -   pipe
  flags=DRhu user=mailsystem argv=/usr/lib/dovecot/deliver -f
${sender} -d ${user}@${nexthop}

malsystem is the user and /usr/lib/dovecot/deliver exists.


Simon



>
> Quoting Simon Brereton :
>
>> Hi
>>
>> I'm very new to Dovecot (been using Courier for 5 years), but I've been 
>> persuaded of the merits of Dovecot and since the server needs upgrading that 
>> seems like the perfect time/excuse.
>>
>> On a test server, I set up postfix and installed Dovecot (running 32-bit 
>> Debian Squeeze, installed from apt-get).  I mirrored the mail store 
>> (Maildirs, for historical reasons located under 
>> /var/spool/mail/virtual/domain.com/user).  Then I ran the courier migration 
>> perl script and everything was fine and dandy.
>>
>> However, when I can to do the production migration, things weren't as 
>> smooth.  The new server is 64-bit (not that I think it makes a difference, 
>> but if you're going to help me you should have all the information :)
>>
>> Again, I installed Postfix and Dovecot
>> Took down the old server
>> Mirrored the Maildirs
>> Ran the migration script
>> Restarted everything
>>
>> At this point everything looked like it was ok.  Mail was being received and 
>> delivered to the Maildirs and the IMAP login was fine.  However, I noticed 
>> errors in the logs when retreiving mail with the MUA along the lines of:
>>
>> Aug 26 16:59:48 mail dovecot: IMAP(si...@lydiard.net): 
>> open(/var/spool/mail/virtual/domain.net/simon/cur/1314328966.V801I166601bM756462.mail.net,S=2461:2,)
>>  failed: Permission denied (euid=999(mailsystem) egid=115(mailsystem) 
>> missing +r perm: 
>> /var/spool/mail/virtual/domain.net/simon/cur/1314328966.V801I166601bM756462.mail.net,S=2461:2,)
>>
>> After messing around with the chown and chmod (even though these were 
>> exactly the same as the test server) I finally discovered the issue.
>>
>> mail:~# ls /var/spool/mail/virtual/domain.net/simon/new/
>> -rwxrwx---  1 postfix mailsystem 2.5K Aug 26 03:33 
>> 1314326000.V801I1666018M803015.mail.net,S=2461:2,
>> -rwxrwx---  1 postfix mailsystem 2.5K Aug 26 03:36 
>> 1314326209.V801I1666019M447273.mail.net,S=2460:2,
>> -rw-rw  1 postfix mailsystem 2.5K Aug 26 04:00 
>> 1314327630.V801I166601aM308173.mail.net,S=2477:2,
>> -rw---  1 postfix mailsystem 2.5K Aug 26 04:22 
>> 1314328966.V801I166601bM756462.mail.net,S=2461:2,
>> -rw---  1 postfix mailsystem 1.1K Aug 26 16:28 
>> 1314372534.V801I166601cM615258.mail.net,S=1097:2,
>> -rw---  1 postfix mailsystem 1.1K Aug 26 16:31 
>> 1314372685.V801I166601dM264242.mail.net,S=1097:2,
>>
>> Mails are being delivered with 0600 permissions and not 0660 (the mails from 
>> courier seem to have all been 0770 as you can see).  If I manually change 
>> the permission (to 0660) then I can see the mail in the MUA.
>>
>> After thinking for a while it occurred to me that this is covered in the LDA 
>> section.  But making changes to the config file (either permissions or 
>> UID/GID) doesn't seem to make a difference.  (Yes, I did restart postfix and 
>> dovecot after the changes).
>>
>> Anyway, here is my dovecot -n:
>>
>> mail:~# dovecot -n
>> # 1.2.15: /etc/dovecot/dovecot.conf
>> # OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.2 ext3
>> log_timestamp: %Y-%m-%d %H:%M:%S
>> protocols: imap imaps pop3 pop3s
>> ssl_ca_file: /etc/ssl/keys/ca.crt
>> ssl_cert_file: /etc/ssl/keys/mail.net.crt
>> ssl_key_file: /etc/ssl/private/mail.net.key
>> 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
>> mail_privileged_group: mailsystem
>> mail_location: maildir:/var/spool/mail/virtual/%d/%n
>> maildir_very_dirty_syncs: yes
>> mbox_write_locks: fcntl dotlock
>> mail_executable(default): /usr/lib/dovecot/imap
>> mail_executable(imap): /usr/lib/dovecot/imap
>> mail_executable(pop3): /usr/lib/dovecot/pop3
>> mail_plugins(default): quota imap_quota
>> mail_plugins(imap): quota imap_quota
>> mail_plugins(pop3): quota
>> mail_plugin_dir(default): /usr/lib/dovecot/modules/imap
>> mail_plu

Re: [Dovecot] Catch22: user needs space to fix out of space condition

[Joseph Tam]

Thanks to all who've made suggestions.  It seems removing dotlocks as
a locking method is the way to go.  There is another dotlock locking
variant mentioned in 10-mail.conf that seems to address this situation
for those that can't get away from dotlocks:

#  dotlock_try: Same as dotlock, but if it fails because of permissions 
or
#   because there isn't enough disk space, just skip it.
mbox_write_locks = dotlock_try fcntl

Joseph Tam 

Re: [Dovecot] File Permissions and delivery

[Patrick Domack]

My guess is your delivering email with postfix to the inbox, instead  
of using dovecot-lda. And something odd is going on with that postfix  
to get odd permissions like that.


You probably needed to edit the postfix virtual deliever transport, or  
maybe you just forget to active the dovecot-lda (deliever) transport.



Quoting Simon Brereton :


Hi

I'm very new to Dovecot (been using Courier for 5 years), but I've  
been persuaded of the merits of Dovecot and since the server needs  
upgrading that seems like the perfect time/excuse.


On a test server, I set up postfix and installed Dovecot (running  
32-bit Debian Squeeze, installed from apt-get).  I mirrored the mail  
store (Maildirs, for historical reasons located under  
/var/spool/mail/virtual/domain.com/user).  Then I ran the courier  
migration perl script and everything was fine and dandy.


However, when I can to do the production migration, things weren't  
as smooth.  The new server is 64-bit (not that I think it makes a  
difference, but if you're going to help me you should have all the  
information :)


Again, I installed Postfix and Dovecot
Took down the old server
Mirrored the Maildirs
Ran the migration script
Restarted everything

At this point everything looked like it was ok.  Mail was being  
received and delivered to the Maildirs and the IMAP login was fine.   
However, I noticed errors in the logs when retreiving mail with the  
MUA along the lines of:


Aug 26 16:59:48 mail dovecot: IMAP(si...@lydiard.net):  
open(/var/spool/mail/virtual/domain.net/simon/cur/1314328966.V801I166601bM756462.mail.net,S=2461:2,) failed: Permission denied (euid=999(mailsystem) egid=115(mailsystem) missing +r perm:  
/var/spool/mail/virtual/domain.net/simon/cur/1314328966.V801I166601bM756462.mail.net,S=2461:2,)


After messing around with the chown and chmod (even though these  
were exactly the same as the test server) I finally discovered the  
issue.


mail:~# ls /var/spool/mail/virtual/domain.net/simon/new/
-rwxrwx---  1 postfix mailsystem 2.5K Aug 26 03:33  
1314326000.V801I1666018M803015.mail.net,S=2461:2,
-rwxrwx---  1 postfix mailsystem 2.5K Aug 26 03:36  
1314326209.V801I1666019M447273.mail.net,S=2460:2,
-rw-rw  1 postfix mailsystem 2.5K Aug 26 04:00  
1314327630.V801I166601aM308173.mail.net,S=2477:2,
-rw---  1 postfix mailsystem 2.5K Aug 26 04:22  
1314328966.V801I166601bM756462.mail.net,S=2461:2,
-rw---  1 postfix mailsystem 1.1K Aug 26 16:28  
1314372534.V801I166601cM615258.mail.net,S=1097:2,
-rw---  1 postfix mailsystem 1.1K Aug 26 16:31  
1314372685.V801I166601dM264242.mail.net,S=1097:2,


Mails are being delivered with 0600 permissions and not 0660 (the  
mails from courier seem to have all been 0770 as you can see).  If I  
manually change the permission (to 0660) then I can see the mail in  
the MUA.


After thinking for a while it occurred to me that this is covered in  
the LDA section.  But making changes to the config file (either  
permissions or UID/GID) doesn't seem to make a difference.  (Yes, I  
did restart postfix and dovecot after the changes).


Anyway, here is my dovecot -n:

mail:~# dovecot -n
# 1.2.15: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.2 ext3
log_timestamp: %Y-%m-%d %H:%M:%S
protocols: imap imaps pop3 pop3s
ssl_ca_file: /etc/ssl/keys/ca.crt
ssl_cert_file: /etc/ssl/keys/mail.net.crt
ssl_key_file: /etc/ssl/private/mail.net.key
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
mail_privileged_group: mailsystem
mail_location: maildir:/var/spool/mail/virtual/%d/%n
maildir_very_dirty_syncs: yes
mbox_write_locks: fcntl dotlock
mail_executable(default): /usr/lib/dovecot/imap
mail_executable(imap): /usr/lib/dovecot/imap
mail_executable(pop3): /usr/lib/dovecot/pop3
mail_plugins(default): quota imap_quota
mail_plugins(imap): quota imap_quota
mail_plugins(pop3): quota
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
imap_client_workarounds(default): outlook-idle delay-newmail
imap_client_workarounds(imap): outlook-idle delay-newmail
imap_client_workarounds(pop3):
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh
lda:
  postmaster_address: postmaster@net
  mail_plugins: quota
  log_path:
  info_log_path:
  deliver_log_format: msgid=%m: %f: %$
auth default:
  mechanisms: plain login
  user: mailsystem
  verbose: yes
  passdb:
driver: sql
args: /etc/dovecot/dovecot-sql.conf
  userdb:
driver: prefetch
  userdb:
driver: static
args: uid=999 gid=115 home=/var/spool/mail/virtual/%d/%n  
allow_all_users=yes

  socket:
type: listen
client:
  path: /var/spool/postfix/private/auth
  mode: 432
  user

Re: [Dovecot] On IMAP vhost login, only Username being used

[hobie]

Found it. :)  Not a dovecot problem but a field in Icedove (Thunderbird
variant) that had been automatically filled in by the software "to serve
you better".  It's on the Server Settings page as "User Name".

"Never mind..." :)

--hobie

> Recapping:  I'm working to set up Dovecot 2.0.13 along with some
additional software (qmail, vpopmail, squirrelmail).  It's working fine
with squirrelmail now, but trying to connect over SSL with a Thunderbird
variant and using IMAP, authentication fails because Dovecot is trying
to match only the front part of the name (the user part), ignoring the
domain name part of what it's being sent.  So, instead of seeking to
match virtual user:
>
>  joe_blow@some_domain.com
>
> ...it's trying to match:
>
>  joe_blow
>
> ...and failing, since joe_blow is not a system user but is a virtual
host user.  With Squirrelmail, connecting from localhost via non-SSL
IMAP, the match is handled correctly, no problem.  I've run the
runtbird.sh script but no light was shed on this by the resulting
output, all it said was that authentication was failing.
>
> Has anyone else encountered this problem?  Any suggestions on how to fix
it or where to look for additional info?  Thanks kindly.
>
> --hobie
>
>> I tried the runtbird.sh script, hoping for more info - all it did was
> show that auth is failing. I don't understand why Dovecot is separating
the username from the domain name, and trying to match only on the
username.  Seems like there must be a config setting that affects this
and that I'm overlooking.  Thanks ahead for any help with this.
>>
>> --hobie
>>
>> hobie wrote earlier:
>>
>> =
>>
>> Attempting IMAP SSL login on new installation, using Icedove (Debain
> Thunderbird variant), login fails.  Logs show Dovecot attempting to
match username only, not username with domain name, on Vpopmail user, so
of course no match. Tried with '@' in full username, also with '%'.
What's missing?
>>
>> Log shows:
>>
>> Aug 24 19:30:48 debian dovecot: auth: Debug: client in: CONT Aug
> 24 19:30:48 debian dovecot: auth: Debug: Loading modules from directory:
/usr/local/lib/dovecot/auth
>> Aug 24 19:30:48 debian dovecot: auth: Debug: vpopmail(postmaster,[IP
> redacted]): lookup user=postmaster domain=
>>
>> Current config:
>>
>> # 2.0.13: /usr/local/etc/dovecot/dovecot.conf
>> # OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.2 ext3
>> auth_debug = yes
>> auth_verbose = yes
>> disable_plaintext_auth = no
>> first_valid_gid = 89
>> first_valid_uid = 89
>> mail_debug = yes
>> mail_location = maildir:/home/vpopmail/domains/%d/%n/Maildir
>> maildir_very_dirty_syncs = yes
>> passdb {
>>   driver = vpopmail
>> }
>> protocols = imap pop3
>> ssl_cert = > ssl_key = > userdb {
>>   args = quota_template=quota_rule=*:backend=%q
>>   driver = vpopmail
>> }
>>
>> --hobie
>>
>> =
>>
>
>
>
>
>
>
>

Re: [Dovecot] performance with 100k messages per folder

[Charles Marcus]

On 2011-08-26 3:07 PM, Florin Andrei  wrote:
> dovecot-2.0-0.10.beta6.20100630.el6.x86_64

Don't need to read further.

Upgrade to a recent stable release - if that doesn't fix your problem,
*then* come back and ask again...

-- 

Best regards,

Charles

[Dovecot] performance with 100k messages per folder

[Florin Andrei]

dovecot-2.0-0.10.beta6.20100630.el6.x86_64 on CentOS 6. Virtual machine 
with 1 GB of RAM on VMWare.


The configuration is more or less stock. Postfix receives then delivers 
to Dovecot. IMAP with mbox. Only one user account, but shared by several 
people via webmail (Roundcube webmail in Apache on the same machine). No 
other MUAs. 100k new messages per month, inbox is rotated monthly into a 
MM folder by a cron job. Only one monthly folder so far. Messages 
are never deleted (but I may start deleting old folders a year or two 
from now). This is mostly for reading, with occasional messages being 
forwarded.


The email was pretty sluggish when logging in to the webmail interface. 
I asked the admin to increase the RAM from 0.5 to 1 GB. I changed 
mbox_very_dirty_syncs to yes. These measures seemed to accelerate it a lot.


There's still a 1 sec pause when logging in, during which time the 
dovecot/imap process is using a lot of CPU.


It looks like, as long as I give it enough RAM to keep the folders in 
memory, the whole thing should be fast enough, which is great. Any other 
tips-n-tricks to keep the email server speedy and the users happy?


Should I worry about mbox_very_dirty_syncs as long as there are no other 
MUAs?


--
Florin Andrei
http://florin.myip.org/

Re: [Dovecot] Virtual user and post-login 2.0.13

[Mark Willcox]

Did you try installing from source after applying the patch?  As in:

This is your problem.. It's a bug in v2.0.13. You could patch with
http://hg.dovecot.org/dovecot-2.0/rev/a2d57b43ccb2 or change config
socket's permissions. I'll hopefully release v2.0.14 in not too distant
future.
-- Timo

That got it working for me.  Plus this:
service imap {
  executable = imap imap-postlogin
}

service imap-postlogin {
  executable = script-login /usr/local/bin/set_postpop
  unix_listener imap-postlogin {
  }
}

The script seems to run as root so I set ownership to the proper user in
the script.

_
Mark Willcox
Data Helper, Inc.


On 8/25/2011 10:47 AM, Pelle Svensson wrote:
> Hi
>
> I tried several variants of suggestions but I can't get it working
>
> dovecot-info.log:
> ===
> Aug 25 17:37:48 imap-login: Info: Login: user=, method=PLAIN, 
> rip=192.168.1.xx, lip=192.168.1.xx, mpid=11264
> Aug 25 17:37:48 imap(vuser): Info: Post-login script denied access to user 
> vuser
>
> dovecot.log
> 
> Aug 25 17:31:28 imap-postlogin: Error: script-login: Error: user 
> p...@bredband.net: Error reading configuration: 
> net_connect_unix(/var/run/dovecot/config) failed: Permission denied
> Aug 25 17:31:28 imap-postlogin: Error: script-login: Fatal: Internal error 
> occurred. Refer to server log for more information.
> Aug 25 17:31:28 log: Error: service(imap-postlogin): child 11082 returned 
> error 89 (Fatal failure)
>
> dovecot.conf
> 
> protocols = imap pop3 
> base_dir = /var/run/dovecot/
>
> log_path = /var/log/dovecot.log
> info_log_path = /var/log/dovecot-info.log
>
> ssl = no # v1.2+, for older versions use: ssl_disable = yes
> disable_plaintext_auth = no
>
> mail_location = maildir:/home/fetchmail/mailroot/dummy
>
> pop3_uidl_format = %08Xu%08Xv
>
>
> !include conf.d/*.conf
> !include_try local.conf
>
> mail_uid=500
> mail_gid=500
>
> auth_verbose = yes
> auth_debug=yes
> auth_debug_passwords=yes
> mail_debug=yes
>
> # Optional tried with this!!!
> service config {
>   unix_listener config {
> group = dovecot
> mode = 0660
>   }
> }
>
> service imap {
>   # tell imap to do post-login lookup using a socket called "imap-postlogin"
>   executable = imap imap-postlogin
> # Optional tried with this!!!
>
>   user=dovecot
> }
>
> # The service name below doesn't actually matter.
> service imap-postlogin {
>   # all post-login scripts are executed via script-login binary
>   executable = script-login /home/fetchmail/dovecot-postlogin.sh
>
>   # the script process runs as the user specified here (v2.0.14+):
> # Optional tried with this!!!
>  
> # user=dovecot
>  #  user = $default_internal_user
>   # this UNIX socket listener must use the same name as given to imap 
> executable
> # Optional tried with this!!!
>
>   #unix_listener imap-postlogin {
>   #}
> }
>
>
> users
> 
> vuser:{PLAIN}pass:500:500::/home/fetchmail::userdb_mail=maildir:/home/fetchmail/mailroot/vuser-root
>  allow_nets=192.168.1.0/24
>
> ls -l /home/fetchmail/dovecot-postlogin.sh
> -rwxrwxrwx. 1 dovecot   root108 Aug 25 17:08 dovecot-postlogin.sh
>
> Any suggestions are very welcome!!
>
> /Thanks
>
>
> 

[Dovecot] File Permissions and delivery

[Simon Brereton]

Hi

I'm very new to Dovecot (been using Courier for 5 years), but I've been 
persuaded of the merits of Dovecot and since the server needs upgrading that 
seems like the perfect time/excuse.

On a test server, I set up postfix and installed Dovecot (running 32-bit Debian 
Squeeze, installed from apt-get).  I mirrored the mail store (Maildirs, for 
historical reasons located under /var/spool/mail/virtual/domain.com/user).  
Then I ran the courier migration perl script and everything was fine and dandy.

However, when I can to do the production migration, things weren't as smooth.  
The new server is 64-bit (not that I think it makes a difference, but if you're 
going to help me you should have all the information :)  

Again, I installed Postfix and Dovecot
Took down the old server
Mirrored the Maildirs
Ran the migration script
Restarted everything

At this point everything looked like it was ok.  Mail was being received and 
delivered to the Maildirs and the IMAP login was fine.  However, I noticed 
errors in the logs when retreiving mail with the MUA along the lines of:

Aug 26 16:59:48 mail dovecot: IMAP(si...@lydiard.net): 
open(/var/spool/mail/virtual/domain.net/simon/cur/1314328966.V801I166601bM756462.mail.net,S=2461:2,)
 failed: Permission denied (euid=999(mailsystem) egid=115(mailsystem) missing 
+r perm: 
/var/spool/mail/virtual/domain.net/simon/cur/1314328966.V801I166601bM756462.mail.net,S=2461:2,)
  
After messing around with the chown and chmod (even though these were exactly 
the same as the test server) I finally discovered the issue.

mail:~# ls /var/spool/mail/virtual/domain.net/simon/new/
-rwxrwx---  1 postfix mailsystem 2.5K Aug 26 03:33 
1314326000.V801I1666018M803015.mail.net,S=2461:2,
-rwxrwx---  1 postfix mailsystem 2.5K Aug 26 03:36 
1314326209.V801I1666019M447273.mail.net,S=2460:2,
-rw-rw  1 postfix mailsystem 2.5K Aug 26 04:00 
1314327630.V801I166601aM308173.mail.net,S=2477:2,
-rw---  1 postfix mailsystem 2.5K Aug 26 04:22 
1314328966.V801I166601bM756462.mail.net,S=2461:2,
-rw---  1 postfix mailsystem 1.1K Aug 26 16:28 
1314372534.V801I166601cM615258.mail.net,S=1097:2,
-rw---  1 postfix mailsystem 1.1K Aug 26 16:31 
1314372685.V801I166601dM264242.mail.net,S=1097:2,

Mails are being delivered with 0600 permissions and not 0660 (the mails from 
courier seem to have all been 0770 as you can see).  If I manually change the 
permission (to 0660) then I can see the mail in the MUA.

After thinking for a while it occurred to me that this is covered in the LDA 
section.  But making changes to the config file (either permissions or UID/GID) 
doesn't seem to make a difference.  (Yes, I did restart postfix and dovecot 
after the changes).

Anyway, here is my dovecot -n:

mail:~# dovecot -n
# 1.2.15: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.2 ext3
log_timestamp: %Y-%m-%d %H:%M:%S
protocols: imap imaps pop3 pop3s
ssl_ca_file: /etc/ssl/keys/ca.crt
ssl_cert_file: /etc/ssl/keys/mail.net.crt
ssl_key_file: /etc/ssl/private/mail.net.key
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
mail_privileged_group: mailsystem
mail_location: maildir:/var/spool/mail/virtual/%d/%n
maildir_very_dirty_syncs: yes
mbox_write_locks: fcntl dotlock
mail_executable(default): /usr/lib/dovecot/imap
mail_executable(imap): /usr/lib/dovecot/imap
mail_executable(pop3): /usr/lib/dovecot/pop3
mail_plugins(default): quota imap_quota
mail_plugins(imap): quota imap_quota
mail_plugins(pop3): quota
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
imap_client_workarounds(default): outlook-idle delay-newmail
imap_client_workarounds(imap): outlook-idle delay-newmail
imap_client_workarounds(pop3):
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh
lda:
  postmaster_address: postmaster@net
  mail_plugins: quota
  log_path:
  info_log_path:
  deliver_log_format: msgid=%m: %f: %$
auth default:
  mechanisms: plain login
  user: mailsystem
  verbose: yes
  passdb:
driver: sql
args: /etc/dovecot/dovecot-sql.conf
  userdb:
driver: prefetch
  userdb:
driver: static
args: uid=999 gid=115 home=/var/spool/mail/virtual/%d/%n allow_all_users=yes
  socket:
type: listen
client:
  path: /var/spool/postfix/private/auth
  mode: 432
  user: postfix
  group: mailsystem
master:
  path: /var/run/dovecot/auth-master
  mode: 432
  user: mailsystem
  group: mailsystem
plugin:
  quota: maildir

As you can see, I tried to go 0660 in both client and master.  

The portion of my master.cf
81 # SPB - Attempt to deliver with Dovecot LDA
 82 dovecot   unix  -   n   n   -   -   pipe
 83   flag

Re: [Dovecot] limiting number of incorrect logins per connection

[Timo Sirainen]

login-common/client-common.h :

#define CLIENT_LOGIN_TIMEOUT_MSECS (MASTER_LOGIN_TIMEOUT_SECS*1000)

So set it to (45*60*1000)

But I don't think there's much of a practical difference between these.

On 26.8.2011, at 12.07, Alex wrote:

> 3 minutes! I think that's too long, how can I drop that down to about 45 
> seconds?
> 
> 
> On Fri, 26 Aug 2011 11:44:45 +0300, Timo Sirainen wrote:
>> On 26.8.2011, at 10.25, Alex wrote:
>> 
>>> Running Dovecot 2 on my server. It is regularly getting dictionary auth 
>>> attacked. What I have noticed is that once connected to a pop3/imap login 
>>> session, you can send endless incorrect usernames+passwords attempts. This 
>>> is a problem for me... I use fail2ban to try and stop these script kiddies. 
>>> The problem is that fail2ban detects the bad auths, firewalls the IP, 
>>> however, since it's an "established" session, the attacker can keep authing 
>>> away... It's only on a subsequent (new) connection that the firewalling 
>>> will take effect.
>> 
>> Umm. If client hasn't managed to log in in 3 minutes, it's
>> disconnected (no matter what it does with the connection).
> 

Re: [Dovecot] limiting number of incorrect logins per connection

[Timo Sirainen]

On 26.8.2011, at 18.27, Allan Cassaro wrote:

> If you substitute (create a wrap to) the "imap-login" binary with an script?
> The script can create a "fail attempt/ip" file into home dir and return ok
> or not to dovecot main process based on this information.

imap-login is typically chrooted and running with nonprivileged account that 
can't access user's home dir. I guess you could change those, but wrapping 
imap-login won't help because you don't know the username at that point..

Either auth or anvil process could do something like this.

Re: [Dovecot] limiting number of incorrect logins per connection

[Allan Cassaro]

On Fri, Aug 26, 2011 at 10:14 AM, Alexandre Chapellon  wrote:

> fail2ban will work as soon as dovecot have closed a none-authenticated
> connection: 3mins->180sec
> If tarpit delay for auth failures in a connection is set to 15s (which
> seems to be the default unless i missunderstood) this let an attackers
> only 12 tries (at most) before IP gets blacklisted by fail2ban... Far enough
> to circumvent bruteforce and even dictionnary based attacks... unless the
> attacker has a botnet and uses non agressives retry policy. But in the last
> case, even if you blacklist IP at first failed  tried, you're still vuln to
> such attacks.
>
> regards.
>
> Le 26/08/2011 14:22, Felipe Scarel a écrit :
>
>  Yeah, I had read about half of that thread, and after I sent my mail kept
>> reading and stumbled upon this: "(...) using the recent module needs
>> dovecotto close the connection upon authentication failure, as iptables
>> only
>> (normally) comes in to play for new connections (...)".
>>
>> So, yeah, my suggestion probably won't work.
>>
>> On Fri, Aug 26, 2011 at 09:15, Felipe Scarel  wrote:
>>
>>  Alex, I've not personally done it (so just speculating here, bear with
>>> me)
>>> but you can customize Fail2Ban's actions if needed. So, if you can match
>>> the
>>> attemps through some regex (and since you're seeing them in the logs,
>>> that
>>> should be quite possible), then you can edit one of the 'actions' to drop
>>> the connection for.
>>>
>>> I'm just not entirely sure that iptables (or pf, or whatever firewall
>>> you've got) can do it to active connections, 'cause that problem hasn't
>>> arised for me so far.
>>>
>>>
>>> On Fri, Aug 26, 2011 at 06:14, Alex  wrote:
>>>
>>>  I am happy to recompile if there is no config option. I gather it's in
 the
 src/auth dir somewhere in one of the C source files. Just need to be
 pointed
 in the right dir.


 On Fri, 26 Aug 2011 19:07:08 +1000, Alex wrote:

  3 minutes! I think that's too long, how can I drop that down to about
> 45 seconds?
>
>
> On Fri, 26 Aug 2011 11:44:45 +0300, Timo Sirainen wrote:
>
>  On 26.8.2011, at 10.25, Alex wrote:
>>
>>  Running Dovecot 2 on my server. It is regularly getting dictionary
>> auth
>>
>>> attacked. What I have noticed is that once connected to a pop3/imap
>>> login
>>> session, you can send endless incorrect usernames+passwords attempts.
>>> This
>>> is a problem for me... I use fail2ban to try and stop these script
>>> kiddies.
>>> The problem is that fail2ban detects the bad auths, firewalls the IP,
>>> however, since it's an "established" session, the attacker can keep
>>> authing
>>> away... It's only on a subsequent (new) connection that the
>>> firewalling will
>>> take effect.
>>>
>>>  Umm. If client hasn't managed to log in in 3 minutes, it's
>> disconnected (no matter what it does with the connection).
>>
>

If you substitute (create a wrap to) the "imap-login" binary with an script?
The script can create a "fail attempt/ip" file into home dir and return ok
or not to dovecot main process based on this information.
This will solve you problem with established connections and will ban the
"badguy" in realtime.

I know this is possible in 1.x version.
Timo, this is possible on 2.x version?

Regards.

-- 
Use cópia oculta (BCC ou CCO) e apague dados pessoais no campo da mensagem
ao encaminhar qualquer e-mail.

http://allan.cassaro.googlepages.com

Re: [Dovecot] limiting number of incorrect logins per connection

[Alexandre Chapellon]

fail2ban will work as soon as dovecot have closed a none-authenticated 
connection: 3mins->180sec
If tarpit delay for auth failures in a connection is set to 15s (which 
seems to be the default unless i missunderstood) this let an 
attackers only 12 tries (at most) before IP gets blacklisted by 
fail2ban... Far enough to circumvent bruteforce and even dictionnary 
based attacks... unless the attacker has a botnet and uses non 
agressives retry policy. But in the last case, even if you blacklist IP 
at first failed  tried, you're still vuln to such attacks.


regards.

Le 26/08/2011 14:22, Felipe Scarel a écrit :

Yeah, I had read about half of that thread, and after I sent my mail kept
reading and stumbled upon this: "(...) using the recent module needs
dovecotto close the connection upon authentication failure, as iptables only
(normally) comes in to play for new connections (...)".

So, yeah, my suggestion probably won't work.

On Fri, Aug 26, 2011 at 09:15, Felipe Scarel  wrote:


Alex, I've not personally done it (so just speculating here, bear with me)
but you can customize Fail2Ban's actions if needed. So, if you can match the
attemps through some regex (and since you're seeing them in the logs, that
should be quite possible), then you can edit one of the 'actions' to drop
the connection for.

I'm just not entirely sure that iptables (or pf, or whatever firewall
you've got) can do it to active connections, 'cause that problem hasn't
arised for me so far.


On Fri, Aug 26, 2011 at 06:14, Alex  wrote:


I am happy to recompile if there is no config option. I gather it's in the
src/auth dir somewhere in one of the C source files. Just need to be pointed
in the right dir.


On Fri, 26 Aug 2011 19:07:08 +1000, Alex wrote:


3 minutes! I think that's too long, how can I drop that down to about
45 seconds?


On Fri, 26 Aug 2011 11:44:45 +0300, Timo Sirainen wrote:


On 26.8.2011, at 10.25, Alex wrote:

  Running Dovecot 2 on my server. It is regularly getting dictionary auth

attacked. What I have noticed is that once connected to a pop3/imap login
session, you can send endless incorrect usernames+passwords attempts. This
is a problem for me... I use fail2ban to try and stop these script kiddies.
The problem is that fail2ban detects the bad auths, firewalls the IP,
however, since it's an "established" session, the attacker can keep authing
away... It's only on a subsequent (new) connection that the firewalling will
take effect.


Umm. If client hasn't managed to log in in 3 minutes, it's
disconnected (no matter what it does with the connection).



--

<>

Re: [Dovecot] limiting number of incorrect logins per connection

[Felipe Scarel]

Yeah, I had read about half of that thread, and after I sent my mail kept
reading and stumbled upon this: "(...) using the recent module needs
dovecotto close the connection upon authentication failure, as iptables only
(normally) comes in to play for new connections (...)".

So, yeah, my suggestion probably won't work.

On Fri, Aug 26, 2011 at 09:15, Felipe Scarel  wrote:

> Alex, I've not personally done it (so just speculating here, bear with me)
> but you can customize Fail2Ban's actions if needed. So, if you can match the
> attemps through some regex (and since you're seeing them in the logs, that
> should be quite possible), then you can edit one of the 'actions' to drop
> the connection for .
>
> I'm just not entirely sure that iptables (or pf, or whatever firewall
> you've got) can do it to active connections, 'cause that problem hasn't
> arised for me so far.
>
>
> On Fri, Aug 26, 2011 at 06:14, Alex  wrote:
>
>> I am happy to recompile if there is no config option. I gather it's in the
>> src/auth dir somewhere in one of the C source files. Just need to be pointed
>> in the right dir.
>>
>>
>> On Fri, 26 Aug 2011 19:07:08 +1000, Alex wrote:
>>
>>> 3 minutes! I think that's too long, how can I drop that down to about
>>> 45 seconds?
>>>
>>>
>>> On Fri, 26 Aug 2011 11:44:45 +0300, Timo Sirainen wrote:
>>>
 On 26.8.2011, at 10.25, Alex wrote:

  Running Dovecot 2 on my server. It is regularly getting dictionary auth
> attacked. What I have noticed is that once connected to a pop3/imap login
> session, you can send endless incorrect usernames+passwords attempts. This
> is a problem for me... I use fail2ban to try and stop these script 
> kiddies.
> The problem is that fail2ban detects the bad auths, firewalls the IP,
> however, since it's an "established" session, the attacker can keep 
> authing
> away... It's only on a subsequent (new) connection that the firewalling 
> will
> take effect.
>

 Umm. If client hasn't managed to log in in 3 minutes, it's
 disconnected (no matter what it does with the connection).

>>>
>>
>

Re: [Dovecot] limiting number of incorrect logins per connection

[Felipe Scarel]

Alex, I've not personally done it (so just speculating here, bear with me)
but you can customize Fail2Ban's actions if needed. So, if you can match the
attemps through some regex (and since you're seeing them in the logs, that
should be quite possible), then you can edit one of the 'actions' to drop
the connection for .

I'm just not entirely sure that iptables (or pf, or whatever firewall you've
got) can do it to active connections, 'cause that problem hasn't arised for
me so far.

On Fri, Aug 26, 2011 at 06:14, Alex  wrote:

> I am happy to recompile if there is no config option. I gather it's in the
> src/auth dir somewhere in one of the C source files. Just need to be pointed
> in the right dir.
>
>
> On Fri, 26 Aug 2011 19:07:08 +1000, Alex wrote:
>
>> 3 minutes! I think that's too long, how can I drop that down to about
>> 45 seconds?
>>
>>
>> On Fri, 26 Aug 2011 11:44:45 +0300, Timo Sirainen wrote:
>>
>>> On 26.8.2011, at 10.25, Alex wrote:
>>>
>>>  Running Dovecot 2 on my server. It is regularly getting dictionary auth
 attacked. What I have noticed is that once connected to a pop3/imap login
 session, you can send endless incorrect usernames+passwords attempts. This
 is a problem for me... I use fail2ban to try and stop these script kiddies.
 The problem is that fail2ban detects the bad auths, firewalls the IP,
 however, since it's an "established" session, the attacker can keep authing
 away... It's only on a subsequent (new) connection that the firewalling 
 will
 take effect.

>>>
>>> Umm. If client hasn't managed to log in in 3 minutes, it's
>>> disconnected (no matter what it does with the connection).
>>>
>>
>

Re: [Dovecot] auth: Error: LDAP: Connection lost to LDAP server, reconnecting

[Angel L. Mateo]

El 25/08/11 12:10, Timo Sirainen escribió:

On 25.8.2011, at 13.04, Angel L. Mateo wrote:


Aug 24 23:07:32 myotis28 dovecot: auth-worker(default): LDAP: Connection lost 
to LDAP server, reconnecting

I have seen in the mail list a patch for 1.2 
(http://hg.dovecot.org/dovecot-1.2/rev/355d5a40f7a7) to ignore these logs when 
the disconnection is because of idle timeouts. As far as I could see in this 
patch and 2.0.13 source code, this patch is already applied in 2.0. So I guess 
that the disconnection is for other problem, isn't it?


I had completely forgotten I had added such a feature :) See what it logs with 
attached patch.

	I have tried the patch. It confirms my hypothesis, the connection is 
closed by my load balancer:


Aug 26 12:55:27 myotis31 dovecot: auth: Error: LDAP: Connection lost to 
LDAP server, reconnecting (1 requests, 3603 idle secs)


	Is there any way to configure ldap connection with a keepalive, so I 
don't need a reconnection?


--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información   _o)
y las Comunicaciones Aplicadas (ATICA)  / \\
http://www.um.es/atica_(___V
Tfo: 868887590
Fax: 86337

Re: [Dovecot] limiting number of incorrect logins per connection

[Alex]

I am happy to recompile if there is no config option. I gather it's in 
the src/auth dir somewhere in one of the C source files. Just need to be 
pointed in the right dir.


On Fri, 26 Aug 2011 19:07:08 +1000, Alex wrote:

3 minutes! I think that's too long, how can I drop that down to about
45 seconds?


On Fri, 26 Aug 2011 11:44:45 +0300, Timo Sirainen wrote:

On 26.8.2011, at 10.25, Alex wrote:

Running Dovecot 2 on my server. It is regularly getting dictionary 
auth attacked. What I have noticed is that once connected to a 
pop3/imap login session, you can send endless incorrect 
usernames+passwords attempts. This is a problem for me... I use 
fail2ban to try and stop these script kiddies. The problem is that 
fail2ban detects the bad auths, firewalls the IP, however, since it's 
an "established" session, the attacker can keep authing away... It's 
only on a subsequent (new) connection that the firewalling will take 
effect.


Umm. If client hasn't managed to log in in 3 minutes, it's
disconnected (no matter what it does with the connection).

Re: [Dovecot] limiting number of incorrect logins per connection

[Alex]

3 minutes! I think that's too long, how can I drop that down to about 
45 seconds?



On Fri, 26 Aug 2011 11:44:45 +0300, Timo Sirainen wrote:

On 26.8.2011, at 10.25, Alex wrote:

Running Dovecot 2 on my server. It is regularly getting dictionary 
auth attacked. What I have noticed is that once connected to a 
pop3/imap login session, you can send endless incorrect 
usernames+passwords attempts. This is a problem for me... I use 
fail2ban to try and stop these script kiddies. The problem is that 
fail2ban detects the bad auths, firewalls the IP, however, since it's 
an "established" session, the attacker can keep authing away... It's 
only on a subsequent (new) connection that the firewalling will take 
effect.


Umm. If client hasn't managed to log in in 3 minutes, it's
disconnected (no matter what it does with the connection).

Re: [Dovecot] limiting number of incorrect logins per connection

[Timo Sirainen]

On 26.8.2011, at 10.25, Alex wrote:

> Running Dovecot 2 on my server. It is regularly getting dictionary auth 
> attacked. What I have noticed is that once connected to a pop3/imap login 
> session, you can send endless incorrect usernames+passwords attempts. This is 
> a problem for me... I use fail2ban to try and stop these script kiddies. The 
> problem is that fail2ban detects the bad auths, firewalls the IP, however, 
> since it's an "established" session, the attacker can keep authing away... 
> It's only on a subsequent (new) connection that the firewalling will take 
> effect.

Umm. If client hasn't managed to log in in 3 minutes, it's disconnected (no 
matter what it does with the connection).

Re: [Dovecot] limiting number of incorrect logins per connection

[a...@ahhyes.net]

Hi,

I saw that thread already, however it does not offer any solution that can be 
applied to dovecot directly. That thread has also been asleep for well over a 
year. It couldnt be that hard for the author to implement this function. It 
would only require a few lines of code.


- Reply message -
From: "Robert Schetterer" 
Date: Fri, Aug 26, 2011 17:59
Subject: [Dovecot] limiting number of incorrect logins per connection
To: 

Am 26.08.2011 09:25, schrieb Alex:
> Hi Guys,
> 
> Running Dovecot 2 on my server. It is regularly getting dictionary auth
> attacked. What I have noticed is that once connected to a pop3/imap
> login session, you can send endless incorrect usernames+passwords
> attempts. This is a problem for me... I use fail2ban to try and stop
> these script kiddies. The problem is that fail2ban detects the bad
> auths, firewalls the IP, however, since it's an "established" session,
> the attacker can keep authing away... It's only on a subsequent (new)
> connection that the firewalling will take effect.
> 
> Why is there no configuration option such as "max auth attempts per
> connection"? This would be useful, so once the limit is reached, the
> connection is dropped.
> 
> is there a patch/workaround?
> 

there where equal questions in the past
i.e read
http://comments.gmane.org/gmane.mail.imap.dovecot/46204

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: [Dovecot] limiting number of incorrect logins per connection

[Robert Schetterer]

Am 26.08.2011 09:25, schrieb Alex:
> Hi Guys,
> 
> Running Dovecot 2 on my server. It is regularly getting dictionary auth
> attacked. What I have noticed is that once connected to a pop3/imap
> login session, you can send endless incorrect usernames+passwords
> attempts. This is a problem for me... I use fail2ban to try and stop
> these script kiddies. The problem is that fail2ban detects the bad
> auths, firewalls the IP, however, since it's an "established" session,
> the attacker can keep authing away... It's only on a subsequent (new)
> connection that the firewalling will take effect.
> 
> Why is there no configuration option such as "max auth attempts per
> connection"? This would be useful, so once the limit is reached, the
> connection is dropped.
> 
> is there a patch/workaround?
> 

there where equal questions in the past
i.e read
http://comments.gmane.org/gmane.mail.imap.dovecot/46204

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

[Dovecot] limiting number of incorrect logins per connection

[Alex]

Hi Guys,

Running Dovecot 2 on my server. It is regularly getting dictionary auth 
attacked. What I have noticed is that once connected to a pop3/imap 
login session, you can send endless incorrect usernames+passwords 
attempts. This is a problem for me... I use fail2ban to try and stop 
these script kiddies. The problem is that fail2ban detects the bad 
auths, firewalls the IP, however, since it's an "established" session, 
the attacker can keep authing away... It's only on a subsequent (new) 
connection that the firewalling will take effect.


Why is there no configuration option such as "max auth attempts per 
connection"? This would be useful, so once the limit is reached, the 
connection is dropped.


is there a patch/workaround?