lmtpd logging

[Etienne Goyer]

Hi,

I am trying to troubleshoot an lmtpd problem.  I currently log local6
and mail facility at debug level, and it seem to work well (ie Postfix 
and Cyrus imapd log verbosely).  However, I can't see anything coming
out of lmtpd.  Which facility, if any, does lmtpd log to ?

-- 
Etienne GoyerLinux Québec Technologies Inc.
http://www.LinuxQuebec.com   [EMAIL PROTECTED]

Re: deleting unwanted mailbox

[Etienne Goyer]

You need the 'c' permission to delete a mailbox. 

sam akos cyrus c


On Mon, Sep 29, 2003 at 04:48:02PM +0200, Miham KEREKES wrote:
> Hi!
> 
> I just wonder, how can I delete a mailbox, which i have created
> accidentally a few minutes ago.
> 
> I wanted to create a user, but somehow forgot the "user." prefix..
> If I want to delete that, I got the response: Permission denied.
> 
> Ideas?
> 
> localhost> lm
> akos (\HasNoChildren)
> [...]
> localhost> dm akos
> deletemailbox: Permission denied
> localhost> lam akos
> cyrus d
> anyone lrs
> 
> Miham.
> -- 
> *
> * Miham KEREKES * Szegedi Tudományegyetem Egyetemi Könyvtár *
> *[ [EMAIL PROTECTED] ]**
> * Aki mindig a sátor tetején van, annak a sátoraljaújhely.. *

-- 
Etienne GoyerLinux Québec Technologies Inc.
http://www.LinuxQuebec.com   [EMAIL PROTECTED]

Re: deleting unwanted mailbox

[Rob Siemborski]

Your user needs the 'c' right (or whatever you configured deleteright to
be)

sam mailbox (your user) c
dm mailbox

-Rob

On Mon, 29 Sep 2003, Miham KEREKES wrote:

> Hi!
>
> I just wonder, how can I delete a mailbox, which i have created
> accidentally a few minutes ago.
>
> I wanted to create a user, but somehow forgot the "user." prefix..
> If I want to delete that, I got the response: Permission denied.
>
> Ideas?
>
> localhost> lm
> akos (\HasNoChildren)
> [...]
> localhost> dm akos
> deletemailbox: Permission denied
> localhost> lam akos
> cyrus d
> anyone lrs
>
> Miham.
> --
> *
> * Miham KEREKES * Szegedi Tudományegyetem Egyetemi Könyvtár *
> *[ [EMAIL PROTECTED] ]**
> * Aki mindig a sátor tetején van, annak a sátoraljaújhely.. *
>
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper

Re: saslauthd, Realms, Cyrus-Imap and LDAP

[Edward Rudd]

Huh, this is odd. as in my tests and live usage of cyrus IMAPd
2.1.14/2.1.15. I am using realms with plain,crammd5, and digestmd5
authentication.. the user logs in as [EMAIL PROTECTED]and the
information gets passed to the ldap server perfectly find and split on
the '@'..  Though I am not using the saslauthd anymore, I am using the
ldapdb auxprop backend that is in the openldap 2.1.x contrib directory.

On Sun, 2003-09-28 at 21:01, Diego Rivera wrote:
> Hello all
> 
> I'm attempting a setup which allows me to have multiple completely
> separate mail domains in my server (separate IMAP boxes, separate
> delivery via Postfix, etc...).
> 
> I've run into one snag though - probably because I don't understand SASL
> as well as I'd like, but please gimme a hand here.
> 
> As it turns out, many different copies of imapd will be running - each
> with their own little (and different configuration).
> 
> I had it all working "fine" with one exception: PLAIN authentication
> doesn't support realms (this I found both in the docs and my testing).
> 
> SASLAUTHD DOES work with the LDAP tree I have, so I'm happy with that. 
> My issue becomes:  How do I tell each Cyrus-IMAP (and its accompanying
> Postfix) instance that ALL its users are in realm X, and that it should
> always FORCE the use of that realm for authentication against saslauthd?
> 
> Since ALL the users that hit a particular IMAP instance will be in the
> same realm (no cross-realm or anything like that), I don't see much of a
> problem with this kind of approach.
> 
> Would a patch for this be too difficult to hack together?  (for me to do
> I mean).
> 
> What other advice can you offer me?
> 
> Best wishes.
> 
> Diego
-- 
Edward Rudd <[EMAIL PROTECTED]>
Home Page 


signature.asc
Description: This is a digitally signed message part

deleting unwanted mailbox

[Miham KEREKES]

Hi!

I just wonder, how can I delete a mailbox, which i have created
accidentally a few minutes ago.

I wanted to create a user, but somehow forgot the "user." prefix..
If I want to delete that, I got the response: Permission denied.

Ideas?

localhost> lm
akos (\HasNoChildren)
[...]
localhost> dm akos
deletemailbox: Permission denied
localhost> lam akos
cyrus d
anyone lrs

Miham.
-- 
*
* Miham KEREKES * Szegedi Tudományegyetem Egyetemi Könyvtár *
*[ [EMAIL PROTECTED] ]**
* Aki mindig a sátor tetején van, annak a sátoraljaújhely.. *

Re: Patch to force realm specifications from IMAPD

[Diego Rivera]

On Mon, 2003-09-29 at 08:17, Igor Brezac wrote:
> The cvs version of saslauthd has ldap_default_realm.

This would not fill the same function - see below.


> Why don't you hard code the realm here "uid=%U,ou=myrealm,o=LDAP"?  You
> run a separate imapd/pop3d/saslauthd/slapd instance for each domain...

Because I'll be using a single saslauthd instance to authenticate all
the imapd (et al) instances - each of those with their own "forced"
realm.  Thus, the '%r' is the determining factor here: it MUST be part
of the filter in order for the namespaces to be completely separate.

Thus, the saslauthd must be able to find users for different realms on
the same LDAP tree, and because there's no other way of telling it how
to find the users for a particular realm, this patch had to be hatched
:)

Is this clearer?  Please tell me if there is (was) an easier way of
accomplishing this.

Kerberos (and other domain-enabled mechanisms) are out of the question
at this point in time.

Best

-- 
===
* Diego Rivera*
* *
* "The Disease: Windows, the cure: Linux" *
* *
* E-mail: lriveraracsacocr  *
* Replace: ='@', ='.'*
* *
* GPG: BE59 5469 C696 C80D FF5C  5926 0B36 F8FF DA98 62AD *
* GPG Public Key avaliable at: http://pgp.mit.edu *
===


signature.asc
Description: This is a digitally signed message part

Re: Patch to force realm specifications from IMAPD

[Igor Brezac]

On Mon, 29 Sep 2003, Diego Rivera wrote:

> Hello all
>
> I ran into a brick wall today because I needed Cyrus-IMAPD to
> authenticate against specific realms, but it would always use the empty
> (default) one regardless of what I told it.
>
> So I came up with this quick patch which adds two config options:
>
> sasl_forced_realm: realm.com (default is null)
>

The cvs version of saslauthd has ldap_default_realm.

> This option causes IMAPD/POP3D/LMTPD* to use the supplied realm spec
> in the sasl_server_new() calls (and thus, authenticate the provided user
> against that realm).  This works well with PLAIN, others may as well.
> I'm well aware that this may break other auth mechanisms, but it fixed
> my problem and others might find it useful.
>
>
> sasl_email_logins: yes|no (default is no)
>
> This causes the realm spec to be set to "", which in turn should
> allow for "email-style" logins specifying a realm.  Naturally, if
> sasl_forced_realm is active this option has no effect.  Again - use with
> care.
>
> More detail on the problem this solved for me:
>
> My problem was that I wanted multiple IMAP instances (using different
> partitions, configurations, ip:port combos, etc) to authenticate against
> particular realms via saslauthd (using LDAP as its backend).
>
> Using fastbind with saslauthd I could then authenticate the user via
> LDAP binds, and find the user's dn via a filter such as
> "uid=%u,ou=%r,o=LDAP".  That way, I can keep separate user spaces,
> separate mailboxes, but run them all on the same box.

Why don't you hard code the realm here "uid=%U,ou=myrealm,o=LDAP"?  You
run a separate imapd/pop3d/saslauthd/slapd instance for each domain...

> Please look it over and comment.
>
> * LMTPD: I realize that preauth could be an issue with LMTPD, so the
> patch does go through the motions to NOT alter behavior if preauth is in
> effect.
>
> Also, since I didn't know (actually, didn't check :) ) if
> imapd/pop3d/lmtpd/etc automagically reload configuration changes the
> configuration values are always read from the config file.  If this is
> not the case, then they could be cached and used indefinitely.
>
> Anyway - here it is.  Please review it and tell me how bad it is :)
>
> Best
>

-- 
Igor

Re: Cyrus 2.1.x / unixhierarchysep: yes and cyradm create inbox

[Etienne Goyer]

In cyradm, do "cm user/mailbox".  Notice that th seprator is now '/'
instead of '.'. Same when you issue IMAP CREATE, etc.

On Mon, Sep 29, 2003 at 02:01:41PM +0200, Marc-Christian Petersen wrote:
> Hi all,
> 
> what syntax do I have to use when creating users inbox folder when I use 
> unixhierarchysep:yes?
> 
> Thanks in advance.
> -- 
> ciao, Marc

-- 
Etienne GoyerLinux Québec Technologies Inc.
http://www.LinuxQuebec.com   [EMAIL PROTECTED]

Re: Cyrus 2.1.x / unixhierarchysep: yes and cyradm create inbox

[Ken Murchison]

Marc-Christian Petersen wrote:

Hi all,

what syntax do I have to use when creating users inbox folder when I use 
unixhierarchysep:yes?
From within cyradm:

cm user/marc

--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26  Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp

Re: followup: stuck lmtpd processes

[Etienne Goyer]

Sorry, I will have to wait til 2.1.16 to test it.  I can't just plug the
fud.c from CVS and compile it, and I am really too busy these day to
make a full checkout from CVS and test it.

I'll report my experience with 2.1.16, if and when it come out.
 
On Wed, Sep 24, 2003 at 01:24:11PM -0400, Etienne Goyer wrote:
> Thanks.  I'll test it by the end of the week, and report.
> 
> On Wed, Sep 24, 2003 at 01:18:12PM -0400, Rob Siemborski wrote:
> > On Wed, 24 Sep 2003, Etienne Goyer wrote:
> > 
> > > > I'll work on fixing fud shortly (its using signal() and it should be
> > > > using sigaction()).
> > >
> > > The included patch against 2.1.13 work for me.
> > 
> > This sort of thing won't work for file locking.  I've just committed a
> > patch to fud that uses sigaction() [Which since we're assuming POSIX
> > anyway, should hopefully be enough].
> > 
> > -Rob
> > 
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
> > Research Systems Programmer * /usr/contributed Gatekeeper
> 
> -- 
> Etienne GoyerLinux Québec Technologies Inc.
> http://www.LinuxQuebec.com   [EMAIL PROTECTED]

-- 
Etienne GoyerLinux Québec Technologies Inc.
http://www.LinuxQuebec.com   [EMAIL PROTECTED]

Re: mailboxes.db problem cont.

[Hank Beatty]

It was indeed the tab at the end of each line that caused the problem. I
added the tab to the end of each line and implemented it about 3 PM
Saturday afternoon and brought the server back on line.

On Sun, 2003-09-28 at 12:14, Rob Siemborski wrote:
> On Sat, 27 Sep 2003, Hank Beatty wrote:
> 
> > Took dir.txt and converted it to the format of mboxlist file (except for
> > the tab on the end of each line. Not sure if this caused a problem)
> 
> This will likely cause a problem with the ACLs.
> 
> > The above steps got POP working, but IMAP gives ???Mailbox does not
> > exist??? when trying to select the ???INBOX??? using squirrelmail.
> 
> I suspect this can be caused by a munged ACL.
> 
> > I also tried using the reconstruct command before and after moving the
> > mailboxes.db to no avail. At this point I???m thinking of writing the
> > ???m option of reconstruct unless anyone has some better ideas or has
> > already written something that might help. While writing the ???m option
> > I might try to figure out why the ???f and ???r options of reconstruct
> > didn???t appear to work in my case. I???m wondering if the ???f and ???r
> > options don???t work because I???m using the fulldirhash option.
> 
> -r means "look at the mailbox list and descend"
> 
> -f means "look at subdirectories" which won't always work quite right on
> top level mailboxes because of how hashing is done.
> 
> Its unlikely fulldirhash affected this at all.
> 
> -Rob
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
> Research Systems Programmer * /usr/contributed Gatekeeper
-- 
Hank Beatty <[EMAIL PROTECTED]>

Cyrus 2.1.x / unixhierarchysep: yes and cyradm create inbox

[Marc-Christian Petersen]

Hi all,

what syntax do I have to use when creating users inbox folder when I use 
unixhierarchysep:yes?

Thanks in advance.
-- 
ciao, Marc

Patch to force realm specifications from IMAPD

[Diego Rivera]

Hello all

I ran into a brick wall today because I needed Cyrus-IMAPD to
authenticate against specific realms, but it would always use the empty
(default) one regardless of what I told it.

So I came up with this quick patch which adds two config options:

sasl_forced_realm: realm.com (default is null)

This option causes IMAPD/POP3D/LMTPD* to use the supplied realm spec
in the sasl_server_new() calls (and thus, authenticate the provided user
against that realm).  This works well with PLAIN, others may as well. 
I'm well aware that this may break other auth mechanisms, but it fixed
my problem and others might find it useful.


sasl_email_logins: yes|no (default is no)

This causes the realm spec to be set to "", which in turn should
allow for "email-style" logins specifying a realm.  Naturally, if
sasl_forced_realm is active this option has no effect.  Again - use with
care.

More detail on the problem this solved for me:

My problem was that I wanted multiple IMAP instances (using different
partitions, configurations, ip:port combos, etc) to authenticate against
particular realms via saslauthd (using LDAP as its backend).

Using fastbind with saslauthd I could then authenticate the user via
LDAP binds, and find the user's dn via a filter such as
"uid=%u,ou=%r,o=LDAP".  That way, I can keep separate user spaces,
separate mailboxes, but run them all on the same box.

Please look it over and comment.

* LMTPD: I realize that preauth could be an issue with LMTPD, so the
patch does go through the motions to NOT alter behavior if preauth is in
effect.

Also, since I didn't know (actually, didn't check :) ) if
imapd/pop3d/lmtpd/etc automagically reload configuration changes the
configuration values are always read from the config file.  If this is
not the case, then they could be cached and used indefinitely.

Anyway - here it is.  Please review it and tell me how bad it is :)

Best
-- 
===
* Diego Rivera*
* *
* "The Disease: Windows, the cure: Linux" *
* *
* E-mail: lriveraracsacocr  *
* Replace: ='@', ='.'*
* *
* GPG: BE59 5469 C696 C80D FF5C  5926 0B36 F8FF DA98 62AD *
* GPG Public Key avaliable at: http://pgp.mit.edu *
===


cyrus-imapd-2.1.15-forced_realm.patch.bz2
Description: application/bzip


signature.asc
Description: This is a digitally signed message part

Re: Postfix, SASL/SASL2 and LDAP

[Luca Olivetti]

Diego Rivera wrote:

My question is: am I totally screwed?  Will I be forced to go to
OpenLDAP 2.1.X and recompile EVERYTHING that touches LDAP (especially
hoping that 2.1.X is backward-compatible with 2.0.X)?


Or just use cooker/9.2 that uses sasl v2 for everything (and also the 
same version of the sleepycat db library, another source of potential 
problems).

Bye

--
Luca Olivetti
Wetron Automatización S.A. http://www.wetron.es/
Tel. +34 93 5883004  Fax +34 93 5883007