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 scr
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..
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 messa
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 f
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 co
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 sec
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/355d
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 dro
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 suggestio
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
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 le
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
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 dow
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 ap
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
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 o
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
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
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
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,
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 transpo
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
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
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
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: do
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
26 matches
Mail list logo