Ed W wrote:
> Bill Landry wrote:
>> Ed W wrote:
>>
>>
>>> failregex = : warning: [-._\w]+\[\]: SASL
>>> (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed$
>>> failregex = dovecot: auth.*\(.*,\): (unknown user|password
>>> mismatch)$
>>>
>>
>> Ed, have you found that both failregex li
Bill Landry wrote:
Ed W wrote:
failregex = : warning: [-._\w]+\[\]: SASL
(?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed$
failregex = dovecot: auth.*\(.*,\): (unknown user|password mismatch)$
Ed, have you found that both failregex lines are actually being used
here, as in my
On Wed, 2009-03-18 at 17:32 +0100, Martin Preen wrote:
> Hello,
> with some mbox folders I got this error:
>
> Mar 18 14:48:12 imap2 dovecot: [ID 107833 mail.crit] Panic:
> IMAP(xyz): file charset-iconv.c: line 122: unreached
Fixed: http://hg.dovecot.org/dovecot-1.1/rev/f65aa01d3222
As for t
Ed W wrote:
> failregex = : warning: [-._\w]+\[\]: SASL
> (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed$
> failregex = dovecot: auth.*\(.*,\): (unknown user|password mismatch)$
Ed, have you found that both failregex lines are actually being used
here, as in my experience, only the fir
Johan,
As far as cert negotiation happens on very early stages of protocol just
write as small program with as many debugging as you want.
-Dmitry
Johan Persson wrote:
Hi,
t's not easily reproducible?
Yes, this is 100% reproducible if you use the "Accept certificate permanently"
when th
WJCarpenter wrote:
Is there any option available for me to help inhibit/prevent
brute-force login attempts?
I (and many others) use fail2ban. It works outside of dovecot, et al,
by tailing your log files. When it finds a configurable
Just to document that solution. This watches postfi
On Thu, 2009-03-19 at 15:25 -0400, David Halik wrote:
> So far
> everything is working smoothly, but when someone does a search through
> directory with a large number of emails, dovecot dies and prints the
> following message:
>
> [ID 107833 mail.crit] Panic: Trying to allocate 2147483648 byte
On 17.03.2009, Bernhard Herzog wrote:
> That's A's INBOX, most likely, so it should be accessible. That it's
> listed but not accessible is AFAICT a combination of two bugs. One is that
> the INBOX's ACL is used as default, so if B as l-permission in A's INBOX
> all of A's mailboxes that do not s
Hi all,
I recently upgraded from courier to dovecot 1.1.12 on a Solaris 9 system
with about 100 users. We have been testing dovecot for sometime in a
mixed Linux/Solaris environment and are aware of the index endianess
issue with multiple archs. To solve this, we run with INDEX=MEMORY (as
se
On Thu, 2009-03-19 at 14:01 +, Mike Brudenell wrote:
> When I upgraded from 1.0.15 I had 1.1.11 telling me off for having the fd
> limit set too low at 2048 when I started Dovecot. Instead it told me to
> raise the limit to at least 10128, so I did. Hence I was a bit surprised to
> find the lim
On Thu, 2009-03-19 at 15:10 +, Mike Brudenell wrote:
> dovecot: Mar 19 13:29:34 Info: imap-login: Disconnected: Connection queue
> full (no auth attempts): rip=144.32.N.N, lip=144.32.N.N
This is the reason why I suggested increasing the max connection count.
There has to be some bug related to
Hi *,
Before going back to the details in this discussion I want to point out
that the whole thing turned out to be really relevant with existing
clients: The Horde based Kolab WebClient expects the behavior as shown
by Cyrus IMAP and fails to show "user/a...@example.com/INBOX" as dovecot
current
Hi (again!) Timo,
2009/3/19 Mike Brudenell
>
> Grepping the code suggests this is presumably coming
> from src/imap-login/client.c
>
> I'm now peering at the code trying to see if I can spot anything, but have
> to confess to not being too wonderful in the area of sockets etc.
>
> Cheers,
> Mike
On Wednesday 18 March 2009 01:50:40 pm you wrote:
> On Wed, 2009-03-18 at 03:32 -0400, Janos Dohanics wrote:
> > > > Fatal: write() failed to info log: Interrupted system call
>
> ..
>
> > Thank you - Dovecot did mysteriously stop may be 2 other times over the
> > past 2 years or so.
>
> Well, that
On Mar 19, 2009, at 7:55 AM, Martin Preen wrote:
Hello,
currently we're using version 1.0.13 with 32bit file offsets.
Is it safe to switch to a new version with largefile support
enabled ?
We want to reuse existing index/cache or do we have to
expect errors with that ?
The cache files won't b
Hi again...
2009/3/19 Mike Brudenell
>
> 2009/3/13 Timo Sirainen
>
>> On Mon, 2009-03-09 at 17:41 +, Mike Brudenell wrote:
>> > We have grown to suspect it is to do with one of the imap-login
>> processes
>> > having a large number of files open. Killing the process seems to get
>> rid of
>
Hi!
Sorry for the delay in replying: I was waiting for the problem to recur so I
could double-check the logs and the states of the imap-login processes.
2009/3/13 Timo Sirainen
> On Mon, 2009-03-09 at 17:41 +, Mike Brudenell wrote:
> > We have grown to suspect it is to do with one of the ima
Hello,
currently we're using version 1.0.13 with 32bit file offsets.
Is it safe to switch to a new version with largefile support
enabled ?
We want to reuse existing index/cache or do we have to
expect errors with that ?
Regards.
Martin
--
Hi,
>t's not easily reproducible?
Yes, this is 100% reproducible if you use the "Accept certificate permanently"
when the client receives the warning that the certificate on the server is not
trusted.
The strange thing is that if you instead use "Accept certificate only this
time" then it wor
19 matches
Mail list logo
