Am 31.10.2012 14:33, schrieb Patrick Boutilier:
>
> This doesn't answer your question but you can still issue the CAPABILITY
> command before logging in.
I see, so you can get the full CAPABILITY-string without being logged
in. I guess the bada device only issues the CAPABILITY co
ented 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
the
> changelog states:
> "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.
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 authentic
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 sen
7,7 +987,7 @@
const char *err;
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, &quo
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 at
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 findin
proxy 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
CA
--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 CAPAB
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
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 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 desc
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 mean
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
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 executa
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
link
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. config_ge
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 r
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 mys
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 ta
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 s
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 wit
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, alph
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
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
Cyru
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 22:21:34.
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
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
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
linked, not stripped
#
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 and then it
riday, August 17, 2001 11:00 PM
Subject: Re: SSL 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 N
hen "Error
initializing TLS"
cc> SSL_connect 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
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+
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
35 matches
Mail list logo
