Hello,
we recently switched from imapd version 2.2.12 to 2.4.12. Now my
cellphone with bada-os 2.0 wont use the idle feature anymore. I assume
the problem lies in the change that happened in version 2.3.4, the
changelog states:
Implemented CAPABILITY response in banner and after authentication
:
Implemented CAPABILITY response in banner and after authentication.
The old version responded something like this:
TLS connection established: TLSv1 with cipher AES256-SHA (256/256 bits)
S: * OK Cyrus IMAP4 v2.2.13-Debian-2.2.13-13ubuntu3 server ready
C: C01 CAPABILITY
S: * CAPABILITY
CAPABILITY response in banner and after authentication.
The old version responded something like this:
TLS connection established: TLSv1 with cipher AES256-SHA (256/256 bits)
S: * OK Cyrus IMAP4 v2.2.13-Debian-2.2.13-13ubuntu3 server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA
Hello everyone,
I'm currently trying to implement the CATENATE extension (RFC 4469) on
client-side, and I am working with Cyrus imapd 2.4.2 (AFAIK, this version is
compliant with this extension). But I encounter some problems to manually
call APPEND CATENATE using imtest. Here is the command I
Wolfgang Breyha wrote, on 25.11.2008 15:35:
Am I right, that either
capa_response(CAPA_PREAUTH);
should return the needed caps for the frontends, too
I tried this, by adding CAPA_POSTAUTH in imapd.c:cmdloop() and my frontends
proxy IDLE to the backends again. This confirms my previous findings
Wolfgang Breyha wrote:
WB I tried this, by adding CAPA_POSTAUTH in imapd.c:cmdloop() and my
WB frontends proxy IDLE to the backends again. This confirms my
WB previous findings and I filed a bug:
WB https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3121
Could you post your patch, please? Or
;
prot_printf(imapd_out, * OK [CAPABILITY );
-capa_response(CAPA_PREAUTH);
+capa_response(CAPA_PREAUTH|CAPA_POSTAUTH);
prot_printf(imapd_out, ]);
if (config_serverinfo) prot_printf(imapd_out, %s, config_servername);
if (config_serverinfo == IMAP_ENUM_SERVERINFO_ON
the IDLE command to the backends, because the frontends
think the backends are not CAPAable to do IDLE.
I searched the source and it seems that there is a problem with the capability
check the frontends do on the backends.
On one hand cyrus announces CAPABILITY in the greeting banner. But
CAPA_PREAUTH
Hi,
Is there a way that I can prevent the proxies on the front end of my Murder
cluster from advertising MAILBOX-REFERRALS in the CAPABILITY string? Or
from issuing referrals?
--
Ian Eiloart
IT Services, University of Sussex
x3148
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki
On 29 Oct 2008, at 09:18, Ian Eiloart wrote:
Is there a way that I can prevent the proxies on the front end of
my Murder
cluster from advertising MAILBOX-REFERRALS in the CAPABILITY
string? Or
from issuing referrals?
There doesn't appear to be a way to disable advertising MAILBOX
--On 29 October 2008 11:25:04 -0400 Wesley Craig [EMAIL PROTECTED] wrote:
On 29 Oct 2008, at 09:18, Ian Eiloart wrote:
Is there a way that I can prevent the proxies on the front end of
my Murder
cluster from advertising MAILBOX-REFERRALS in the CAPABILITY
string? Or
from issuing referrals
Hi,
In the changelist for cyrus imap 2.3.13, is this:
Added support for IMAP [CAPABILITY] response code to client-side of Murder
proxies
I have little clue what that means, but I'm hoping it means I can change my
CAPABILITY response string. Does it?
My underlying problem here is that my
On Fri, 24 Oct 2008, Ian Eiloart wrote:
Hi,
In the changelist for cyrus imap 2.3.13, is this:
Added support for IMAP [CAPABILITY] response code to client-side of Murder
proxies
I have little clue what that means, but I'm hoping it means I can change my
CAPABILITY response string. Does
On 24 Oct 2008, at 13:09, Andrew Morgan wrote:
Use the following option, which was added in 2.3.13:
proxyd_disable_mailbox_referrals: 0
Set to true to disable the use of mailbox-referrals on
the proxy
servers.
This fixes the exact problem you describe
Alex Deiter wrote:
Hi,
Cyrus IMAP on 64bit arch incorrectly interprets defaults numerical
parameters of a imapd.conf: all of them are equal to zero!
For example, compile source in attach:
# gcc -m64 test.c
# file a.out
a.out: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
On Feb 26, 2005, at 2:54 PM, Amos wrote:
Alex Deiter wrote:
Hi,
Cyrus IMAP on 64bit arch incorrectly interprets defaults numerical
parameters of a imapd.conf: all of them are equal to zero!
For example, compile source in attach:
# gcc -m64 test.c
# file a.out
a.out: ELF 64-bit MSB
On Tue, 4 Jan 2005, Derrick J Brashear wrote:
--- lib/imapopts.h.orig Fri Dec 31 10:19:47 2004
+++ lib/imapopts.h Fri Dec 31 10:20:13 2004
@@ -200,9 +200,9 @@
const char *s;
- int i;
+ long i;
- int b;
+ long b;
enum enum_value e;
given that e.g.
On Fri, 31 Dec 2004, Alex Deiter wrote:
--- lib/imapopts.h.orig Fri Dec 31 10:19:47 2004
+++ lib/imapopts.h Fri Dec 31 10:20:13 2004
@@ -200,9 +200,9 @@
const char *s;
- int i;
+ long i;
- int b;
+ long b;
enum enum_value e;
given that e.g. config_getint
info-cyrus -- Amos Gouaux wrote:
Cyrus-IMAP 2.1.x and 2.2.x (up to 2.2.3) work fine on sparc64. After
2.2.4 (on 2.2.10) i got error:
Dec 27 21:23:19 satira nntp[24755]: DBERROR db4: PANIC: fatal region
error detected; run recovery
So do you compile Berkeley DB for 64-bit? Haven't tried it yet
Alex Deiter wrote:
Henrique de Moraes Holschuh wrote:
Cyrus IMAP on 64bit arch incorrectly interprets defaults numerical
parameters of a imapd.conf: all of them are equal to zero!
Can't confirm on alpha, gcc 3.3.5:
And while I haven't tried with 2.2, Debian has 2.1 compiled for at least
ia64,
On Fri, 31 Dec 2004, info-cyrus -- Amos Gouaux wrote:
Alex Deiter wrote:
Henrique de Moraes Holschuh wrote:
Cyrus IMAP on 64bit arch incorrectly interprets defaults numerical
parameters of a imapd.conf: all of them are equal to zero!
Can't confirm on alpha, gcc 3.3.5:
And while I haven't tried
On Fri, 31 Dec 2004, Igor Brezac wrote:
You cannot compile cyrus 64-bit and use 32-bit Berkeley or any other libs.
Indeed. You usually can not mix 32-bit libs with 64-bit ones or 64-bit apps,
unless you take very great pains to do so, or the OS does this for you (most
don't), AND your platform
On Fri, 31 Dec 2004, Henrique de Moraes Holschuh wrote:
On Fri, 31 Dec 2004, Igor Brezac wrote:
You cannot compile cyrus 64-bit and use 32-bit Berkeley or any other libs.
I meant to say any other 32-bit lib.
Indeed. You usually can not mix 32-bit libs with 64-bit ones or 64-bit apps,
unless you
On Thu, 30 Dec 2004 01:22:48 +0300
Alex Deiter [EMAIL PROTECTED] wrote:
Hi,
Cyrus IMAP on 64bit arch incorrectly interprets defaults numerical
parameters of a imapd.conf: all of them are equal to zero!
Can't confirm on alpha, gcc 3.3.5:
alphabox:~# gcc test.c
alphabox:~# file a.out
a.out:
On Fri, 31 Dec 2004, Jure Pe_ar wrote:
Cyrus IMAP on 64bit arch incorrectly interprets defaults numerical
parameters of a imapd.conf: all of them are equal to zero!
Can't confirm on alpha, gcc 3.3.5:
And while I haven't tried with 2.2, Debian has 2.1 compiled for at least
ia64, alpha and
I'm seeing the same thing on Solaris 8, 9, and 10 (s10_69) using a
not so old cc (-xarch=v9 option) and gcc 3.3.3 (-m64). These are all
on sparc boxes. I got non-zero values by changing 'int' to 'long'.
Amos
--- test.c 2004-12-30 22:09:33.793048000 -0600
+++ test2.c 2004-12-30
Amos wrote:
I'm seeing the same thing on Solaris 8, 9, and 10 (s10_69) using a not
so old cc (-xarch=v9 option) and gcc 3.3.3 (-m64). These are all on
sparc boxes. I got non-zero values by changing 'int' to 'long'.
Quite right!
--
Alex Deiter
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Henrique de Moraes Holschuh wrote:
Cyrus IMAP on 64bit arch incorrectly interprets defaults numerical
parameters of a imapd.conf: all of them are equal to zero!
Can't confirm on alpha, gcc 3.3.5:
And while I haven't tried with 2.2, Debian has 2.1 compiled for at least
ia64, alpha and amd64. It is
I am running Yellowdog 2.1 (Redhat 7.1 repackaged) with Postfix 1.1.3,
Cyrus-SASL 1.5.24, Cyrus-IMAP 2.0.16. I have finally gotten cyradm to run,
but it does nothing after running cyradm localhost and requires a ^C to get
out. When I run imtest localhost then I get C: CO1 CAPABILITY
capability
Hey chirs,
Friday, August 17, 2001, 4:47:08 PM, you wrote:
cc Hello,
cc I am trying to get TLS working with Cyrus. This is
cc what I am seeing in the Header for
cc S01 NO Error initializing TLS
I don't use SSL yet, but I think it's saying S01 NO, then Error
initializing TLS
cc
Hello,
I am trying to get TLS working with Cyrus. This is
what I am seeing in the Header for
imtest -t foo.foobar
catfish# imtest -t catfish.jmqa.net
C: C01 CAPABILITY
S: * OK catfish Cyrus IMAP4 v2.0.16 server ready
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+
NAMESPACE UIDPLUS ID
error -1
cc SSL session removed
cc TLS negotiation failed!
cc C: C01 CAPABILITY
cc S: Invalid tag
cc S: * BAD Invalid tag
cc This seems to say No Error but then after is says
cc error. There doesn't seem to be much to go on here.
cc Can anybody help out with this?
cc Again Thanks
See above
On Fri, 3 Aug 2001, Sam Roberts wrote:
I'm trying to find the definition of AUTH=ANONYMOUS, but
RFC2060 says look in RFC1731, and 1731 doesn't define
anonymous.
The ANONYMOUS SASL Mechanism is defined in RFC 2245.
All of the SASL mechanism assignments (and referances for each) are listed
33 matches
Mail list logo
