ed take a look at
sounds very interesting - i planned to write a similiar open source product
(after the very flexible web-cyradm was very outdated) - but with exim /
pam_mysql (should be similiar) and reserved some spare time over christmas
and january for it...
After planning with django years ago, my
sting - i planned to write a similiar open source product
(after the very flexible web-cyradm was very outdated) - but with exim /
pam_mysql (should be similiar) and reserved some spare time over christmas
and january for it...
After planning with django years ago, my current plan was to
Hi cyrus list.
(This email contains self promotion of a cyrus/imap related piece of
software..)
I wrote some years ago (and recently updated) a small django application
for cyrus and postfix,
with database lookup tables.
It has self service support. The system has 3 roles "admin","domain
Thanks! You have the more correct fix:
From: https://www.openssl.org/docs/man1.1.0/man3/TLSv1_client_method.html
"TLS_method(), TLS_server_method(), TLS_client_method()
These are the general-purpose version-flexible SSL/TLS methods. The
actual protocol version used will be negotiated to the hi
Thanks for reporting back. For whatever its worth, the equivalent fix on 2.5+
uses "TLS_client_method()", not "TLSv1_2_client_method()". I'm not sure what
difference it makes, but maybe it requires a newer OpenSSL than you have?
Here's the commit to master, fyi:
https://github.com/cyrusimap/cyr
3.EL7) built from the Red Hat SRC RPM. We also have
> SASL, Utils, devel etc pkgs all from RH.
>
> Now we're looking to finally move Cyrus completely off insecure TLS versions.
> But now there is a lingering issue...
>
> We removed tls1_0 from impad.conf, and the
secure TLS
versions. But now there is a lingering issue...
We removed tls1_0 from impad.conf, and the CYRADM shell stopped working.
We can no longer connect at all:
CYRADM -U CYRUS
[ SSL_CONNECT ERROR -1 ]
[ SSL SESSION REMOVED ]
[ TLS NEGOTIATION DID NOT SUCCEED ]
CYRADM: CANNOT AUTHENTICATE
Thanks Ellie,
https://github.com/cyrusimap/cyrus-imapd/issues/2747
--
Ismaël
Le 26/04/2019 à 10:11, ellie timoney a écrit :
Hi Ismaël,
Which version of perl are you running? (`perl --version` will tell
you) A fairly newish one, I guess?
The cyradm tools
Hi Ismaël,
Which version of perl are you running? (`perl --version` will tell you) A
fairly newish one, I guess?
The cyradm tools were written using a quite old version of perl, which didn't
produce a lot of warnings. I expect it's working fine, but your newer perl
version is
Hello,
I've got this error after connecting to cyrus with cyradm (as root or
cyrus user):
# cyradm -u cyrus localhost
Variable "$cyrref" will not stay shared at
/usr/lib64/perl5/vendor_perl/Cyrus/IMAP/Shell.pm line 724.
Variable "$lfh" will not stay shared at
/us
ary issue. The real
culprit is how the run function is implemented.
Let's consider the original code for that function again:
# trivial; wrapper for _run with correct setup
sub run {
my $cyradm;
_run(\$cyradm, [*STDIN, *STDOUT, *STDERR], *__DATA__);
}
How should *__DATA__ have become a
ariable *never* is assigned any value during normal program
execution, meaning that _run() always is called with undef as its last
parameter.
As a proof, I have replaced the following code
# trivial; wrapper for _run with correct setup
sub run {
my $cyradm;
_run(\$cyradm, [*STDIN, *STDOUT, *STDE
ot; is not correct enough!
There are many aspects I didn't understand yet. To me, it seems that
_run is called with a bunch of uninitialized parameters. For example,
where are $cyradm and *__DATA__ initialized? I am currently lacking the
time to do my homework (i.e. to completely understand how
ve the time at the moment). It seems that the code which parses the
> command line and the run parameters in Cyrus::IMAP::Shell is buggy (or
> at least not prepared to handle Term::ReadLine::Gnu).
>
> As a proof, I have reinstalled Term::ReadLine:Gnu and verified that the
> proble
ne and the run parameters in Cyrus::IMAP::Shell is buggy (or
at least not prepared to handle Term::ReadLine::Gnu).
As a proof, I have reinstalled Term::ReadLine:Gnu and verified that the
problem was showing again.
Then I have replaced the following code in Cyrus::IMAP::Shell
# trivial; wrapper
error go away, and it seems that I can
execute scripts now.
So you have provided the solution and solved the problem.
However, there is a downside. I am using cyradm quite often, mainly for
setting permissions in a large shared folder (i.e. public) hierarchy.
For this reason, I really need the nice
}
> }
Which... fills me with confidence. Looks like a workaround for missing
(broken?) Term::Readline but that comment isn't super enlightening. I wonder
if it will Just Work if you uninstall Term::Readline?
I haven't really used cyradm at all myself, so take all this with a grain o
Dear all,
I was just trying to explore cyradm a little bit further and hence was
experimenting with its scripting capabilities. Having cyradm run a script
should be pretty easy. man cyradm tells us:
perl -MCyrus::IMAP::Shell -e 'run("myscript")'
So I created the simp
e aid of TLS
> Certificates only.
> I do not use the POP3 protocol at all.
> I do not use unsecured connections at all.
> Everything goes over TLS/sasl authentication/authorization.
>
> However...
> If it comes to testsaslauthd, imtest or cyradm I can't connect to
> loca
connections at all.
Everything goes over TLS/sasl authentication/authorization.
However...
If it comes to testsaslauthd, imtest or cyradm I can't connect to
localhost.localdomain (via SSH) on my remote server or get a 'can't connect to
server' (cyradm) reply.
I'm pretty sure it
in/quota with
and without -f all report correct values for quota.
Only thing that does not work is cyradm for reading qoutas, "set quota"
works.
I think I'm giving up on this one for now because it is not a problem
really production-wise.
Thanks,
>
> El 21/8/17 a las 8:
Have you copied from another machine or similar the quota database??
You should never do that
Best regards,
El 21/8/17 a las 8:42, Per olof Ljungmark escribió:
On 2017-08-21 08:11, Egoitz Aurrekoetxea wrote:
Good morning,
What happens if you launch the cyradm from a remote machine
On 2017-08-21 08:11, Egoitz Aurrekoetxea wrote:
Good morning,
What happens if you launch the cyradm from a remote machine?. For
instance in a FreeBSD with another Perl version?. Does it work?.
No, tried that and results are the same. Current line of thought is that
something is not right
Good morning,
What happens if you launch the cyradm from a remote machine?. For
instance in a FreeBSD with another Perl version?. Does it work?.
Best regards,
El 19/8/17 a las 13:18, Per olof Ljungmark escribió:
Hi all,
Wonder if someone can offer help.
Host is FreeBSD 11.0-STABLE #0
Hi all,
Wonder if someone can offer help.
Host is FreeBSD 11.0-STABLE #0 r316644M and cyrus 2.5.11 in a jail.
If I run cyradm as user cyrus (admin) and issue the lq command, usually
there is a proper response at first, but subsequent commands fail. This
could very well be a FreeBSD problem but I
Hi Ken,
Zitat von Ken Murchison :
Try user/foo instead of user.foo
poorly this doesn't help...:
localhost> info user/foo
Mailbox does not exist
localhost> info user^foo
Mailbox does not exist
localhost> info user.foo
Mailbox does not exist
localhost> lam user.foo
cyrus lrswipkxtecda
localhos
oject/show/home:nixda:branches:home:nixda:devel).
Poorly there must be something wrong somehow... somewhere... on an
"fresh" and new system with no mailbox I did the following steps:
mailfr-hx:~ # cyradm --user cyrus localhost
Password:
localhost> lm *
localhost> lm user.foo
localh
ng somehow... somewhere... on an
"fresh" and new system with no mailbox I did the following steps:
mailfr-hx:~ # cyradm --user cyrus localhost
Password:
localhost> lm *
localhost> lm user.foo
localhost> info user.foo
Mailbox does not exist
localhost> cm user.foo
loca
e in?
>
> Cheers,
>
> ellie
>
> On Fri, Apr 7, 2017, at 12:29 AM, Olaf Frączyk wrote:
> > Hello,
> >
> > cyrus-imapd-2.5.10-2.3.el7.x86_64 from open build system
> >
> > I have set metadata for mailboxes:
> >
> > t3 SETMETADATA "INBOX/Sen
t" (/private/specialuse "\\Sent")
>
> I can see the metadata from imap connection and from cyradm but only
> when logged as user:
>
> t3 LIST (SPECIAL-USE) "" "*"
> * LIST (\HasNoChildren \Drafts) "/" INBOX/Drafts
> * LIST (\HasNoChildr
Hello,
cyrus-imapd-2.5.10-2.3.el7.x86_64 from open build system
I have set metadata for mailboxes:
t3 SETMETADATA "INBOX/Sent" (/private/specialuse "\\Sent")
I can see the metadata from imap connection and from cyradm but only
when logged as user:
t3 LIST (SPECIA
Dan,
You nailed it. Mere presence of sasldb plugin makes it work.
The code doesn't look kosher to me though.
In sasl_server_new() there's a line:
serverconn->sparams->canon_user = &_sasl_canon_user_lookup;
which unconditionally set canon_user callback to the function that performs both
canonical
In the absence of an [sasl_]auxprop_plugins statement, all plugins will be
queried. For example, running pluginviewer (or saslpluginviewer on debian)
should typically list sasldb if it's installed on your system.
The canon_user plugins and auxprop plugins are coded within the same code,
and so ar
-u t...@virtualcrap.com
localhost
connecting to localhost
Please enter your password:
log:
Nov 17 18:24:11 rway-imap-vm sieve[2247]: TLS is available.
Nov 17 18:24:15 rway-imap-vm saslauthd[1167]: pam_userdb(sieve:auth): user
't...@virtualcrap.com' granted access
Nov 17 18:24:15 rwa
;>>> proxyservers: proxyadmin
> >>>> sasl_pwcheck_method: saslauthd
> >>>> #sasl_pwcheck_method: alwaystrue
> >>>> sasl_mech_list: PLAIN
> >>>> allowplaintext: yes
> >>>>
> >>>> here's what i do:
> &
hod: alwaystrue
> >>>> sasl_mech_list: PLAIN
> >>>> allowplaintext: yes
> >>>>
> >>>> here's what i do:
> >>>>
> >>>> root@rway-imap-vm:~# sieveshell -a proxyadmin -u t...@virtualcrap.com
> >>>
if i try to authorize as different user. if i don't
everything works fine:
root@rway-imap-vm:~# sieveshell -a t...@virtualcrap.com -u t...@virtualcrap.com
localhost
connecting to localhost
Please enter your password:
log:
Nov 17 18:24:11 rway-imap-vm sieve[2247]: TLS is available.
Nov 1
; Nov 17 18:24:46 rway-imap-vm sieve[2256]: Lost connection to client --
> >> exiting
> >>
> >> as you can see user proxyadmin authenticated successfully, but then
> >> something (authorization?) went wrong
> >> and it says "PLAIN no mechanism avail
ualcrap.com -u t...@virtualcrap.com
localhost
connecting to localhost
Please enter your password:
log:
Nov 17 18:24:11 rway-imap-vm sieve[2247]: TLS is available.
Nov 17 18:24:15 rway-imap-vm saslauthd[1167]: pam_userdb(sieve:auth): user
't...@virtualcrap.com' granted access
Nov 17 18:2
rway-imap-vm sieve[2247]: TLS is available.
> Nov 17 18:24:15 rway-imap-vm saslauthd[1167]: pam_userdb(sieve:auth): user
> 't...@virtualcrap.com' granted access
> Nov 17 18:24:15 rway-imap-vm sieve[2247]: login: localhost [127.0.0.1]
> t...@virtualcrap.com PLAIN User logged in
>
map-vm sieve[2247]: TLS is available.
Nov 17 18:24:15 rway-imap-vm saslauthd[1167]: pam_userdb(sieve:auth): user
't...@virtualcrap.com' granted access
Nov 17 18:24:15 rway-imap-vm sieve[2247]: login: localhost [127.0.0.1]
t...@virtualcrap.com PLAIN User logged in
the same happend
On 08/26/2016 09:47 AM, Tod A. Sandman via Info-cyrus wrote:
I noticed after upgrading from cyrus-imapd-2.3.16 to cyrus-imapd-2.5.9 that the
"info" cyradm command no longer works: it prints out nothing. Furhermore,
after issuing the info command, no other commands print anything ei
Are you sure that you are using the cyradm from 2.5.9? IIRC, older
cyradm doesn't like the responses sent by 2.5.x servers.
On 08/26/2016 10:47 AM, Tod A. Sandman via Info-cyrus wrote:
I noticed after upgrading from cyrus-imapd-2.3.16 to cyrus-imapd-2.5.9 that the
"info" cy
I noticed after upgrading from cyrus-imapd-2.3.16 to cyrus-imapd-2.5.9 that the
"info" cyradm command no longer works: it prints out nothing. Furhermore,
after issuing the info command, no other commands print anything either. For
instance:
cyrus@cyrus2a:/var/imap/sync>
On 06/05/16 04:24, Stuart Castergine via Info-cyrus wrote:
> C: A01 AUTHENTICATE PLAIN Y3lydXMAY3lydXMAaGVsbC1oYXRoLW5vLWZ1cnk=
I recommend changing the password from the "fury" thingy to something else.
Maybe you want to strip base64 encoded credentials in the future.
Greetings, Wolfgang
--
Wol
ter
> wrote:
>
>> > I am trying to set up a basic system with cyrus-imap and postfix on
>> amazon
>> > linux
>> >
>> > I can connect using imtest, but cannot connect with cyradm:
>> >
>> > Additionally, when I connect via a client with
I can connect using imtest, but cannot connect with cyradm:
> >
> > Additionally, when I connect via a client with a user I know has mail,
> > it's
> > saying that no INBOX exists. Postfix's mail spool is /var/spool/mail, but
> > I
> > don't see a
> I am trying to set up a basic system with cyrus-imap and postfix on amazon
> linux
>
> I can connect using imtest, but cannot connect with cyradm:
>
> Additionally, when I connect via a client with a user I know has mail,
> it's
> saying that no INBOX exists. Postf
I am trying to set up a basic system with cyrus-imap and postfix on amazon
linux
I can connect using imtest, but cannot connect with cyradm:
Additionally, when I connect via a client with a user I know has mail, it's
saying that no INBOX exists. Postfix's mail spool is /var/spool/m
Just a quick note: IMAP::Admin appears to be broken, at the moment, and
can't be compiled. The Debian people submitted a patch 3 months ago
with no activity, indicating that the Perl module is semi-abandoned.
On 9/17/2015 3:03 PM, Patrick Boutilier wrote:
> On 09/17/2015 04:07 PM, Patrick Goet
That could be easily tested with "lam " COMMAND.
On 2015-09-18 03:40, Patrick Goetz wrote:
> Interesting. When I use cyradm to set up a new account, I always
> execute 2 commands:
>
>cyradm --user administrator localhost
>
>localhost> cm user/daffy
a essa mensagem
informando o acontecido.
Em 17/09/2015 17:40:01, Patrick Goetz escreveu:
> Interesting. When I use cyradm to set up a new account, I always
execute 2 commands:
cyradm --user administrator localhost
localhost> cm user/daffyduck
localhost> sam user/daffyduck
, 17 Sep 2015, at 02:33 AM, Patrick Goetz wrote:
>> pgoetz@www:~$ cyradm --user administrator localhost
>> perl: symbol lookup error:
>> /usr/lib/perl5/site_perl/auto/Cyrus/IMAP/IMAP.so: undefined symbol:
>> Perl_xs_apiversion_bootcheck
>> I'm running Arch lin
Interesting. When I use cyradm to set up a new account, I always
execute 2 commands:
cyradm --user administrator localhost
localhost> cm user/daffyduck
localhost> sam user/daffyduck daffyduck write
Does this mean that the second command has been superfluous all along
and that
On 09/17/2015 04:07 PM, Patrick Goetz wrote:
Thanks. I'm just now getting around to looking at this script. This
creates a mailbox, but don't you also need to set access privileges for
the user associated with this mailbox?
Only if you are going to change the default rights. User will have
a
Thanks. I'm just now getting around to looking at this script. This
creates a mailbox, but don't you also need to set access privileges for
the user associated with this mailbox?
On 09/16/2015 12:00 PM, Patrick Boutilier wrote:
>
> We use this simple perl script to add users. Fill in appropr
On Thu, 17 Sep 2015, at 02:33 AM, Patrick Goetz wrote:
> pgoetz@www:~$ cyradm --user administrator localhost perl: symbol
> lookup error: /usr/lib/perl5/site_perl/auto/Cyrus/IMAP/IMAP.so:
> undefined symbol: Perl_xs_apiversion_bootcheck
>
>
> I'm running Arch linux, whi
this morning I tried to create a new user using cyradm and got
a perl error message:
pgoetz@www:~$ cyradm --user administrator localhost
perl: symbol lookup error:
/usr/lib/perl5/site_perl/auto/Cyrus/IMAP/IMAP.so: undefined symbol:
Perl_xs_apiversion_bootcheck
I'm running Arch linux,
ion: 5.22.0
However, this morning I tried to create a new user using cyradm and got
a perl error message:
pgoetz@www:~$ cyradm --user administrator localhost
perl: symbol lookup error:
/usr/lib/perl5/site_perl/auto/Cyrus/IMAP/IMAP.so: undefined symbol:
Perl_xs_apiversion_bootcheck
I&#x
So, I've been happily avoiding upgrading cyrus imap because everything
has been working and I'm generally in the "if it ain't broke, don't fix
it" category.
Cyrus version: 2.4.17
Perl version: 5.22.0
However, this morning I tried to create a new user usin
2014-11-06 14:29 GMT-02:00 Andreas Pflug :
> Using cyradm to add mailboxes and do some acl stuff isn't too convenient
> if you're not doing it 50 times a day and you're a command line geek. So
> I hacked up an IMAP plugin to the Admin4 framework as cyradm
> replacement.
Using cyradm to add mailboxes and do some acl stuff isn't too convenient
if you're not doing it 50 times a day and you're a command line geek. So
I hacked up an IMAP plugin to the Admin4 framework as cyradm
replacement. It should work on any IMAP server, but has only been tested
o
On 02/21/14 16:33 +0100, Willy Offermans wrote:
>This sounds interesting. I thought that in
>slapd.conf was forcing this behavior. I like to read more about the
>EXTERNAL mechanism. Do you recommend some reading?
>
>At the moment I will stick to PLAIN and play with replication, serving
>multiple d
derive the username
> (with no password, per se). For example, 'cyradm --tlskey '.
>
> The EXTERNAL mechanism should not be offered unless TLS client
> authentication was successful during the starttls step.
>
> --
> Dan White
This sounds interesting. I thought th
TLS client authentication is a scenario where you perform TLS
authentication where the client also has a certificate. The server can
then use the contents of the client certificate to derive the username
(with no password, per se). For example, 'cyradm --tlskey '.
The EXTERNAL mechanism
Hallo Dan,
On Fri, Feb 21, 2014 at 08:50:41AM -0600, Dan White wrote:
> On 02/21/14 10:50 +0100, Willy Offermans wrote:
> >Indeed, I needed to specify an authentication mechanism and then I could
> >use the command line interface of cyradm:
> >
> >cyradm --user user
On 02/21/14 10:50 +0100, Willy Offermans wrote:
>Indeed, I needed to specify an authentication mechanism and then I could
>use the command line interface of cyradm:
>
>cyradm --user username --auth PLAIN localhost
>
>If we are at this point anyway, I was wondering what I need to
y new FreeBSD 10.0 server. I have used the
> > following
> > package: cyrus-imapd24-2.4.17_4
> >
> > If I test my setup with imtest, I get connection to the imap server.
> >
> > MyName@MyComputer:~$ imtest -m login -u username -a username -s localhost
> >
>
if cyrus is your user admin just do
cyradm --user cyrus --server localhost
and it will work
depending on your password backend you may need to add user cyrus with
sasldb2 or
if you use local unix account with saslauthd you just need to set a
password for user cyrus with passwd
On 2/20/14
t my setup with imtest, I get connection to the imap server.
>
> MyName@MyComputer:~$ imtest -m login -u username -a username -s localhost
>
>
>
> However, if I try to connect via cyradm, I cannot login.
>
> MyName@MyComputer:~$ cyradm --user username localhost
> Password:
>
;t
> >read/write key database /etc/opiekeys: Permission denied
> >Feb 19 09:00:39 MyComputer imaps[3437]: login: localhost [127.0.0.1]
> >username plaintext+TLS User logged in
> >SESSIONID=
> >Feb 19 09:02:18 MyComputer imaps[3437]: USAGE username user: 0.0075
t
>read/write key database /etc/opiekeys: Permission denied
>Feb 19 09:00:39 MyComputer imaps[3437]: login: localhost [127.0.0.1] username
>plaintext+TLS User logged in SESSIONID=
>Feb 19 09:02:18 MyComputer imaps[3437]: USAGE username user: 0.007544 sys:
>0.022632
>
>However
sername
plaintext+TLS User logged in SESSIONID=
Feb 19 09:02:18 MyComputer imaps[3437]: USAGE username user: 0.007544 sys:
0.022632
However, if I try to connect via cyradm, I cannot login.
MyName@MyComputer:~$ cyradm --user username localhost
Password:
verify error:num=19:self signed certific
those unknowns I guess we'll just let it go.
>
>Thanks,
>Reg
>
>
>Monday, January 23, 2012, 9:40:45 AM, you wrote:
>
>> On 01/21/12 02:59 -0800, Reg Proctor wrote:
>>>Hi,
>
>>>I just want to confirm that logging into cyradm as I am experiencing it
On 01/21/12 02:59 -0800, Reg Proctor wrote:
>Hi,
>
>I just want to confirm that logging into cyradm as I am experiencing it
>is normal and that lm is behaving as it should be. It seems a little
>unusual to me.
>
>
>First cyradm logging in, here is what I am seeing:
>
&g
Hi,
I just want to confirm that logging into cyradm as I am experiencing it
is normal and that lm is behaving as it should be. It seems a little
unusual to me.
First cyradm logging in, here is what I am seeing:
To log into cyradm I have to set my defaultdomain to localhost and then
I can
But after some fights with
plugin for check quota in the Squirrelmail I tried a command for
listing quota in the "cyradm". Command mentioned above didn't
reconstructed usage. Reconstruction of the usage works fine only in
the "cyradm". But it doesn't accept wildcard &
onstruct -r -f
>>> user." seems to be all fine. But after some fights with
>>> plugin for check quota in the Squirrelmail I tried a command for
>>> listing quota in the "cyradm". Command mentioned above didn't
>>> reconstructed usage. Reconstructio
hts with
plugin for check quota in the Squirrelmail I tried a command for
listing quota in the "cyradm". Command mentioned above didn't
reconstructed usage. Reconstruction of the usage works fine only in
the "cyradm". But it doesn't accept wildcard "*" to recon
t; plugin for check quota in the Squirrelmail I tried a command for
> listing quota in the "cyradm". Command mentioned above didn't
> reconstructed usage. Reconstruction of the usage works fine only in
> the "cyradm". But it doesn't accept wildcard &qu
I believe the wildcard is a % not a *. Try using % or since you are dealing
with user accounts, user.% or user/% whichever way your options are set.
On Jul 21, 2011, at 1:17 AM, Josef Karliak wrote:
> reconstructing not in the cyradm reconstructs mails and folders, not the
> quota that
Hi,
reconstructing not in the cyradm reconstructs mails and folders,
not the quota that I need to reconstruct :-/
localhost> reconstruct *
reconstruct: Mailbox does not exist
localhost> reconstruct user.*
reconstruct: Mailbox does not exist
localhost> reconstruct
usage: recons
or
> listing quota in the "cyradm". Command mentioned above didn't
> reconstructed usage. Reconstruction of the usage works fine only in
> the "cyradm". But it doesn't accept wildcard "*" to reconstruct all
> mailboxes. So there is a question
ota in the "cyradm". Command mentioned above didn't
reconstructed usage. Reconstruction of the usage works fine only in
the "cyradm". But it doesn't accept wildcard "*" to reconstruct all
mailboxes. So there is a question - how to reconstruct all ? Any ideas
Spellman wrote:
>>We have recently upgraded to cyrus 2.4.6. Our environment includes
>>a server running as a murder server, four back end mailstores, and
>>two front end servers. If we mistakenly create a user mailbox on
>>one of the front end servers using cyradm, and
er mailbox on one of
the front end servers using cyradm, and then try to manage it (dm,
sam, info, lm), cpu load on the front end server increases until the
box is unusable. Syslogs show the user cyrus (our admin user) logging
in over and over, each time creating a new proxyd process, which
e
It appears that the front end does know that it has the mailbox:
[cyrus@postoffice09 ~]$ cyr_dbtool `pwd`/mailboxes.db skiplist show
user.frodo
user.frodo1 postoffice09.bates.edu!default frodolrswipkxtecda
The backend knows nothing about the user frodo:
[cyrus@mailstore07 ~]$ cyr_db
On 01/07/11 09:10 -0400, Robert Spellman wrote:
>We have recently upgraded to cyrus 2.4.6. Our environment includes a
>server running as a murder server, four back end mailstores, and two
>front end servers. If we mistakenly create a user mailbox on one of
>the front end servers
We have recently upgraded to cyrus 2.4.6. Our environment includes a
server running as a murder server, four back end mailstores, and two
front end servers. If we mistakenly create a user mailbox on one of the
front end servers using cyradm, and then try to manage it (dm, sam,
info, lm), cpu
enable the parameter:
>
> proxyd_disable_mailbox_referrals: 1
>
> With 2.3.16 dont have problem to issue commands direct in frontends
> using cyradm.
>
> cyradm --user cyrus frontend2316
>
> info user/mailbox - OK
> lam user/mailbox - OK
> sam user/m
I'm not sure what the story is with this one. Ken might have a better
idea since they use murder and cyradm at CMU (I just use telnet
directly or Perl modules that talk pure IMAP, and we don't use
murder at FastMail). I've CC'd him.
Would be great if you can create bugs in b
problem to issue commands direct in frontends
using cyradm.
cyradm --user cyrus frontend2316
info user/mailbox - OK
lam user/mailbox - OK
sam user/mailbox - OK
cm user/mailbox - OK
With 2.4.X :
cyradm --user cyrus frontend241
info user/mailbox - OK
lam user/mailbox - OK
sam user
On 04 Oct 2010, at 13:37, Patrick Goetz wrote:
> On 10/04/2010 12:29 PM, Andrew Morgan wrote:
>> cyrus-be4:~# cyradm --user cyrus --tlskey '' localhost
>
> That did it! The trick is to use --tlskey with an empty field as
> demonstrated above. Who knew?
That's a
;m using saslauthd, pam, and have a
>self-signed certificate (which I know works):
saslauthd does not support shared secret mechanisms (you'd need to use an
auxprop plugin to do so).
with cyradm, you'd choose the mechanism with the '--auth' option. See:
http://www.cyru
On Mon, 4 Oct 2010, Patrick Goetz wrote:
> On 10/04/2010 12:29 PM, Andrew Morgan wrote:
>>
>> cyrus-be4:~# cyradm --user cyrus --tlskey '' localhost
>
>
> That did it! The trick is to use --tlskey with an empty field as
> demonstrated above. Who knew?
&g
On 10/04/2010 12:29 PM, Andrew Morgan wrote:
>
> cyrus-be4:~# cyradm --user cyrus --tlskey '' localhost
That did it! The trick is to use --tlskey with an empty field as
demonstrated above. Who knew?
--
ibis:~~$ cyradm --user pgoetz --tlskey '' localhost
verif
On Mon, 4 Oct 2010, Patrick Goetz wrote:
> On 10/04/2010 08:41 AM, Wesley Craig wrote:
>>
>> TLS isn't available to Cyrus::IMAP pre 2.3.2. I expect it's a bug.
>
>
> Sorry,I didn't specifically say that I'm using the latest release, 2.3.16.
>
>
2.3.16-1
Cyrus mail system - common files
ibis:~~$ cyradm localhost
Login disabled.
cyradm: cannot authenticate to server as pgoetz
ibis:~~$
> Why would you suppose it's a dead tool? Because it has a bug?
>
I'm just asking because it's not working for me when I disable pl
h I know works):
-
ibis:~~$ cyradm --auth digest-md5 --tlskey
/etc/ssl/private/ssl-cert-mail.internetbs.com.key localhost
[ unable to get certificate from
'/etc/ssl/private/ssl-cert-mail.internetbs.com.key' ]
[ TLS engine: cannot load cert/key data, might be a
On 04 Oct 2010, at 10:26, Patrick Goetz wrote:
> Sorry,I didn't specifically say that I'm using the latest release, 2.3.16.
I understood that, tho I did notice you pasted the 2.2.x error, not the 2.3.x
error.
> I find cyradm to be very convenient to use for smaller sites
1 - 100 of 1126 matches
Mail list logo
