Hi list,
this question is related to the IMAP protocol itself, not really to
Dovecot.
I'm trying to understand what is the more efficient way to maintain the
number of unseen messages of the currently selected mailbox. RFC3501 says a
client must not issue a STATUS command to the selected mailbox
On 14/04/2012 04:48, Stan Hoeppner wrote:
On 4/13/2012 10:31 AM, Ed W wrote:
You mean those "answers" like:
"you need to read 'those' articles again"
Referring to some unknown and hard to find previous emails is not the
same as answering?
No, referring to this:
On 4/12/2012 5:58 AM, Ed
On Fri, Apr 13, 2012 at 07:33:19AM -0500, Stan Hoeppner wrote:
> >
> > What I meant wasn't the drive throwing uncorrectable read errors but
> > the drives are returning different data that each think is correct or
> > both may have sent the correct data but one of the set got corrupted
> > on the
On 14/04/2012 04:31, Stan Hoeppner wrote:
On 4/13/2012 10:31 AM, Ed W wrote:
On 13/04/2012 13:33, Stan Hoeppner wrote:
In closing, I'll simply say this: If hardware, whether a mobo-down SATA
chip, or a $100K SGI SAN RAID controller, allowed silent data corruption
or transmission to occur, ther
On Fri, 13 Apr 2012 12:13:30 -0400
Michael Orlitzky articulated:
> Exchange... the cure is worse than the disease! This isn't looking
> good -- I guess I'll continue to do what I have been: telling people
> to switch off of Outlook if they want their mail client to not suck.
First of all, there a
Timo Sirainen wrote:
>> But two libraries are not quite okay. They don't find their SSL libs:
>>
>> libdovecot-lda.so
>> libdovecot-storage.so
>
> Maybe this fixes it?
>
> http://hg.dovecot.org/dovecot-2.1/rev/8b91367bc3e1
Works perfectly! Great, now all components find their li
Some time ago I complained about very slow access to compressed mboxes.
Unfortunately it looks like that it is very little interest in it, so I
have to investigate some things by myself.
Firstly: some rationale.
Why do I prefer use mbox/maildir over mdbox. Short answer "bus factor"
for support md
I have a question about sieve pipe: can it return something to further
processing?
For example in procmail I can do:
--8<---cut here---start->8---
:0
VIRUS=`$CLAMSCAN --mbox --disable-summary --stdout -`
--8<---cut here---end
Version: 2.1.4
OS: Gentoo stable/amd64
OpenSSL version: 1.0.0h
I'm having a slight problem with the client certificates in Dovecot
2.1.4. I've set-up the client certificate verification/authentication,
and it seems that Dovecot is choking on the trustchain with CRL's that
I'm providing to it (atta
hey all, im getting the following error:
Apr 14 14:29:44 lmtpdirector1 dovecot: auth: Error: passdb(scorpio,127.0.0.1):
Auth client doesn't have permissions to do a PASS lookup:
/var/run/dovecot/auth-userdb mode=0666, but not owned by UID 112(dovecot)
Apr 14 14:29:44 lmtpdirector1 dovecot: lmt
Of course the moment I post I seem to have figured it out..
service auth {
unix_listener auth-userdb {
mode = 0777
}
}
Is this safe if your servers are secure?
Cor
Am 14.04.2012 um 18:24 schrieb Cor Bosman:
> Apr 14 14:29:44 lmtpdirector1 dovecot: auth: Error:
> passdb(scorpio,127.0.0.1): Auth client doesn't have permissions to do a PASS
> lookup: /var/run/dovecot/auth-userdb mode=0666, but not owned by UID
> 112(dovecot)
> Apr 14 14:29:44 lmtpdirector1 d
> > Apr 14 14:29:44 lmtpdirector1 dovecot: auth: Error:
> > passdb(scorpio,127.0.0.1): Auth client doesn't have permissions to do a
> > PASS lookup: /var/run/dovecot/auth-userdb mode=0666, but not owned by UID
> > 112(dovecot)
> > Apr 14 14:29:44 lmtpdirector1 dovecot: lmtp(18298): Error: user s
Op 4/14/2012 2:13 PM, Kamil Jońca schreef:
I have a question about sieve pipe: can it return something to further
processing?
For example in procmail I can do:
--8<---cut here---start->8---
:0
VIRUS=`$CLAMSCAN --mbox --disable-summary --stdout -`
--8<-
On 4/14/2012 5:04 AM, Jan-Frode Myklebust wrote:
> On Fri, Apr 13, 2012 at 07:33:19AM -0500, Stan Hoeppner wrote:
>>>
>>> What I meant wasn't the drive throwing uncorrectable read errors but
>>> the drives are returning different data that each think is correct or
>>> both may have sent the correct
On 4/14/2012 5:00 AM, Ed W wrote:
> On 14/04/2012 04:48, Stan Hoeppner wrote:
>> On 4/13/2012 10:31 AM, Ed W wrote:
>>
>>> You mean those "answers" like:
>>> "you need to read 'those' articles again"
>>>
>>> Referring to some unknown and hard to find previous emails is not the
>>> same as answ
16 matches
Mail list logo
