Re: imapd unavailable when a lot of connections are started from inetd
On Tue, 5 Mar 2002, Alain == Alain Tesio wrote: Alain Hello, Alain When I make a lot of connections with cyradm in a row, the connection Alain fails after processing some of them, I don't know where this limit Alain comes from, the problem is that the imap server is definitely not Alain available, see details below Alain Is it a known behaviour when imapd is started from inetd, do you Alain consider this as a vulnerability to a DOS attack ? From the inetd man page: The optional ``max'' suffix (separated from ``wait'' or ``nowait'' by a dot) specifies the maximum number of server instances that may be spawned from inetd within an interval of 60 seconds When omitted, ``max'' defaults to 40 -d
timsieved and saslauthd
Folks, RedHat have a great .spec file for sasl1+2 combined in their rawhide development snapshot. You might want to check it out, I'm using it now. How do I convince timsieved to use saslauthd? It seems to want to use sasldb. Feb 6 11:45:52 polaris timsieved[20740]: Could not open db Feb 6 11:45:52 polaris timsieved[20740]: Could not open db Feb 6 11:45:52 polaris timsieved[20740]: no secret in database I've put various things in the sasl2 plugin dir: [root@polaris sasl2]# pwd /usr/lib/sasl2 [root@polaris sasl2]# cat timsieved.conf pwcheck_method:saslauthd [root@polaris sasl2]# cat Sieve.conf pwcheck_method:saslauthd [root@polaris sasl2]# but they're not getting picked up. I would have thought my Cyrus.conf would have been enough anyway . . . ? Thanks for any info. -Darren
Re: timsieved and saslauthd
On Wed, 6 Feb 2002, Darren == Darren Nickerson wrote: Darren How do I convince timsieved to use saslauthd? It seems to want to use Darren sasldb. Darren Feb 6 11:45:52 polaris timsieved[20740]: Could not open db Darren Feb 6 11:45:52 polaris timsieved[20740]: Could not open db Darren Feb 6 11:45:52 polaris timsieved[20740]: no secret in database I should have been more clear. I'm trying to use sieveshell to manage sieve scripts, but I'm unable to authenticate using saslauthd. Will sieveshell one day know about different auth methods? Installsieve used to, according to the manpage, though its current commandline shows no evidence of supporting it. In the end, I fudged the authentication by creating sasldb2 for now (allowing DIGEST-MD5 to succeed), which brought me to my next problem. The following looked like a login failure: [darren@polaris darren]$ sieveshell --user=darren localhost connecting to localhost Please enter your password: unable to connect to server: Authentication error at /usr/bin/sieveshell line 170, STDIN line 1. but was really the inability to create (or absence of) the sieve directory tree it seems to have been looking for. This must have been something I missed in the setup docs? Feb 6 22:13:52 polaris master[31465]: about to exec /usr/cyrus/bin/timsieved Feb 6 22:13:52 polaris service-sieve[31465]: executed Feb 6 22:13:52 polaris service-sieve[31465]: accepted connection Feb 6 22:13:54 polaris timsieved[31465]: mkdir /usr/sieve/d/darren: No such file or directory Feb 6 22:13:54 polaris timsieved[31465]: error in actions_setuser() Feb 6 22:13:54 polaris master[868]: process 31465 exited, status 75 -Darren -- Darren Nickerson Chief Technology Officer iWorkwell, Inc. 215.875.9550 (voice) 215.882.3266 (cell) 215.243.8335 (fax) HR Made Easy.(tm) The information contained in this email message is intended only for the personal and confidential use of the recipient(s) named above. This message may contain confidential and/or privileged material. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please contact the sender immediately, and delete the original message.
Re: timsieved and saslauthd
WHOA! Where the heck has THAT! message been? I have to say, it was a bit surreal to have posted this question on the 6th, and then to have seen several threads about it emerge in the past week, all asking a similar question ;-) Received: from lists2.andrew.cmu.edu (LISTS2.ANDREW.CMU.EDU [128.2.10.216]) by mail.iworkwell.com (Postfix) with ESMTP id D7297B4624 for [EMAIL PROTECTED]; Wed, 13 Feb 2002 14:47:59 -0500 (EST) Received: (from postman@localhost) by lists2.andrew.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) id g16KQrHt001232 for info-cyrus-list; Wed, 6 Feb 2002 15:26:53 -0500 (EST) *phew* 7 days sitting on lists2.andrew.cmu.edu. Poor little e-mail . . . I hope you were occasionally feeding it! Is this a moderation/approval workflow issue? -Darren On Wed, 6 Feb 2002, Darren == Darren Nickerson wrote: Darren Folks, Darren RedHat have a great .spec file for sasl1+2 combined in their rawhide Darren development snapshot. You might want to check it out, I'm using it now. Darren How do I convince timsieved to use saslauthd? It seems to want to Darren use sasldb. Darren Feb 6 11:45:52 polaris timsieved[20740]: Could not open db Darren Feb 6 11:45:52 polaris timsieved[20740]: Could not open db Darren Feb 6 11:45:52 polaris timsieved[20740]: no secret in database Darren I've put various things in the sasl2 plugin dir: Darren [root@polaris sasl2]# pwd Darren /usr/lib/sasl2 Darren [root@polaris sasl2]# cat timsieved.conf Darren pwcheck_method:saslauthd Darren [root@polaris sasl2]# cat Sieve.conf Darren pwcheck_method:saslauthd Darren [root@polaris sasl2]# Darren but they're not getting picked up. I would have thought my Cyrus.conf would Darren have been enough anyway . . . ? Darren Thanks for any info. Darren -Darren
timsieved and saslauthd
Folks, RedHat have a great .spec file for sasl1+2 combined in their rawhide development snapshot. You might want to check it out, I'm using it now. How do I convince timsieved to use saslauthd? It seems to want to use sasldb. Feb 6 11:45:52 polaris timsieved[20740]: Could not open db Feb 6 11:45:52 polaris timsieved[20740]: Could not open db Feb 6 11:45:52 polaris timsieved[20740]: no secret in database I've put various things in the sasl2 plugin dir: [root@polaris sasl2]# pwd /usr/lib/sasl2 [root@polaris sasl2]# cat timsieved.conf pwcheck_method:saslauthd [root@polaris sasl2]# cat Sieve.conf pwcheck_method:saslauthd [root@polaris sasl2]# but they're not getting picked up. I would have thought my Cyrus.conf would have been enough anyway . . . ? Thanks for any info. -Darren
Postfix + SASL2 . . . anyone working on this?
Folks,
Has anyone convinced postfix to play nicely with SASL2? Looks like the API has
changed for too much for the current SASL support.
I tried compiling postfix-1.1.3 with:
CCARGS=${CCARGS} -DUSE_SASL_AUTH -I/usr/include/sasl
AUXLIBS=${AUXLIBS} -lsasl2
(where /usr/include/sasl points to the sasl2 includes)
And it dies with:
gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE -I/usr/include/pcre
-DHAS_MYSQL -I/usr/include/mysql -DUSE_SASL_AUTH -I/usr/include/sasl -DHAS_SSL
-I/usr/include/openssl -DHAS_DBM -DPATH_NDBM_H='gdbm/ndbm.h' -O2 -march=i386
-mcpu=i686 -I. -I../../include -DLINUX2 -c smtpd_sasl_glue.c
smtpd_sasl_glue.c: In function `smtpd_sasl_log':
smtpd_sasl_glue.c:120: `SASL_LOG_WARNING' undeclared (first use in this function)
smtpd_sasl_glue.c:120: (Each undeclared identifier is reported only once
smtpd_sasl_glue.c:120: for each function it appears in.)
smtpd_sasl_glue.c:123: `SASL_LOG_INFO' undeclared (first use in this function)
smtpd_sasl_glue.c: In function `smtpd_sasl_connect':
smtpd_sasl_glue.c:200: warning: passing arg 4 of `sasl_server_new' from incompatible
pointer type
smtpd_sasl_glue.c:200: warning: passing arg 6 of `sasl_server_new' from incompatible
pointer type
smtpd_sasl_glue.c:200: too few arguments to function `sasl_server_new'
smtpd_sasl_glue.c:232: warning: passing arg 6 of `sasl_listmech' from incompatible
pointer type
smtpd_sasl_glue.c: In function `smtpd_sasl_authenticate':
smtpd_sasl_glue.c:292: warning: passing arg 4 of `sasl_decode64' makes integer from
pointer without a cast
smtpd_sasl_glue.c:292: too few arguments to function `sasl_decode64'
smtpd_sasl_glue.c:301: warning: passing arg 5 of `sasl_server_start' from incompatible
pointer type
smtpd_sasl_glue.c:301: too many arguments to function `sasl_server_start'
smtpd_sasl_glue.c:346: warning: passing arg 4 of `sasl_decode64' makes integer from
pointer without a cast
smtpd_sasl_glue.c:346: too few arguments to function `sasl_decode64'
smtpd_sasl_glue.c:352: warning: passing arg 4 of `sasl_server_step' from incompatible
pointer type
smtpd_sasl_glue.c:352: too many arguments to function `sasl_server_step'
smtpd_sasl_glue.c:373: warning: passing arg 3 of `sasl_getprop' from incompatible
pointer type
make: *** [smtpd_sasl_glue.o] Error 1
make: *** [update] Error 1
Thanks in advance for any info.
-Darren
--
Darren Nickerson
Chief Technology Officer
iWorkwell, Inc.
215.875.9550 (voice)
215.882.3266 (cell)
215.243.8335 (fax)
HR Made Easy.(tm)
The information contained in this email message is intended only for the
personal and confidential use of the recipient(s) named above. This message
may contain confidential and/or privileged material. If the reader of this
message is not the intended recipient or an agent responsible for delivering
it to the intended recipient, you are hereby notified that you have received
this document in error and that any review, dissemination, distribution, or
copying of this message is strictly prohibited. If you have received this
communication in error, please contact the sender immediately, and delete
the original message.
Re: sieve sasl2
On Thu, 31 Jan 2002,Jure == Jure Pecar wrote: Jure Hi list, Jure I have a cyrus 2.1.1 authenticating via saslauthd -a pam. When i telnet to Jure sieve port, i get: Jure $ telnet 0 2000 Jure Trying 0.0.0.0... Jure Connected to 0. Jure Escape character is '^]'. Jure IMPLEMENTATION Cyrus timsieved v1.1.0 Jure SIEVE fileinto reject envelope vacation imapflags notify subaddress Jure regex OK I had the same problem, which turned out to be due to an incorrect path to sasl2's plugins. I have sasl and sasl2 coexisting on the same box, so: /usr/lib/sasl2 /usr/lib/sasl are two very different beasts. Sadly, when I had compiled sasl2, I had forgotten to give configure the: --with-plugindir=/usr/lib/sasl2 flag. So it was looking in the default (incorrect version) /usr/lib/sasl and was failing to load the plugins. Do you get anything logged in syslog? The following entries in syslog.conf: # Cyrus imapd sasl local6.debug/var/log/imapd.log auth.debug /var/log/auth.log should tell you why sasl is not getting any auth methods. -Darren
imaps - intermittent connection failures
Folks, I'm unable to get cyrus-imapd's SSL support to offer reliable service, and I was wondering if anyone might recognize the problem. Essentially every SECOND connection to imaps fails. My test case is fetchmail client connection to imaps, but I see the problem with Outlook 2000 as well. When the connection fails, it looks like: fetchmail: awakened by User defined signal 1 fetchmail: background fetchmail at 28206 awakened. fetchmail: awakened at Mon, 26 Mar 2001 20:43:22 -0500 (EST) fetchmail: 5.5.0 querying some.host.iworkwell.com (protocol IMAP) at Mon, 26 Mar 2001 20:43:22 -0500 (EST) [darren@alden1 darren]$ 28206:error:140770FC:SSL routines:SSL23_GET_SERVER_HELL O:unknown protocol:s23_clnt.c:458: fetchmail: SSL connection failed. fetchmail: fetchmail: sleeping at Mon, 26 Mar 2001 20:43:22 -0500 (EST) Whereas when it succeeds: [darren@alden1 darren]$ fetchmail fetchmail: awakened by User defined signal 1 fetchmail: background fetchmail at 28206 awakened. fetchmail: awakened at Mon, 26 Mar 2001 20:45:15 -0500 (EST) fetchmail: 5.5.0 querying some.host.iworkwell.com (protocol IMAP) at Mon, 26 Mar 2001 20:45:15 -0500 (EST) [darren@alden1 darren]$ fetchmail: Issuer Organization: iWorkwell, Inc. fetchmail: Issuer CommonName: some.host.iworkwell.com fetchmail: Server CommonName: some.host.iworkwell.com fetchmail: Issuer Organization: iWorkwell, Inc. fetchmail: Issuer CommonName: some.host.iworkwell.com fetchmail: Server CommonName: some.host.iworkwell.com fetchmail: IMAP * OK something.iworkwell.com Cyrus IMAP4 v2.0.12 server ready fetchmail: IMAP A0001 CAPABILITY fetchmail: IMAP * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT MULTIAPPEND SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE STARTTLS AUTH=GSSAPI AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 X-NETSCAPE fetchmail: IMAP A0001 OK Completed fetchmail: IMAP A0002 AUTHENTICATE CRAM-MD5 fetchmail: IMAP + PDM0MjMzNzI2NTYuMTI1NzkwNDZAbWFpbC5pd62ya3dlbGwuY29tPg== I'm hoping there's a "me too" out there . . . does this look familar to anyone? -Darren
LMTP AUTH? (Cyrus imapd + Postfix)
Folks, I'm trying to deliver mail to a Cyrus mailstore using postfix's LMTP over TCP functionality. Is there any way to get LMTP AUTH to work, or do I just have to settle for running Cyrus's lmtpd with the "-a" flag? That results in: Mar 19 01:01:34 mail2 lmtpd[30269]: connection from [xxx.xx.xx.xx] preauth'd as postman and delivery succeeds . . . of course anyone could now connect and dump mail to Cyrus :-( Which leads to the next question . . . can I get TCP wrappers involve here? I'd like to restrict access to lmtpd. Thanks in advance. -Darren
RH7 + cyrus imapd CVS - undefined symbol: imclient_connect
Folks, I wasn't able to get 2.0.12 to compile on Redhat-7 (all updates applied): gcc -c -I.. -I/usr/include/db3 -I/usr/local/include -I/usr/include/et -I/usr/include/db3 -I/usr/include/db1 -I/usr/include -I/usr/include -DHAVE_CONFIG_H -I. -I. -O2 -march=i386 -mcpu=i686 -fPIC \ util.c util.c:54: conflicting types for `malloc' /usr/include/stdlib.h:526: previous declaration of `malloc' make[1]: *** [util.o] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/cyrus-imapd-2.0.12/lib' make: *** [all] Error 1 Bad exit status from /var/tmp/rpm-tmp.86452 (%build) So I figured I'd try the CVS version. I got much farther, only now after installing cyrus I get: [root@mail2 postfix]# cyradm localhost perl: error while loading shared libraries: /usr/lib/perl5/site_perl/5.6.0/i386 -linux/auto/Cyrus/IMAP/IMAP.so: undefined symbol: imclient_connect [root@mail2 SPECS]# ldd /usr/lib/perl5/site_perl/5.6.0/i386-linux/auto/Cyrus/IM AP/IMAP.so libsasl.so.7 = /usr/lib/libsasl.so.7 (0x40006000) libssl.so.0 = /usr/lib/libssl.so.0 (0x40011000) libcrypto.so.0 = /usr/lib/libcrypto.so.0 (0x4003f000) libc.so.6 = /lib/libc.so.6 (0x40105000) libgdbm.so.2 = /usr/lib/libgdbm.so.2 (0x4022e000) libdl.so.2 = /lib/libdl.so.2 (0x40235000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x40238000) libpam.so.0 = /lib/libpam.so.0 (0x40265000) libresolv.so.2 = /lib/libresolv.so.2 (0x4026d000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) [root@mail2 SOURCES]# rpm -q cyrus-sasl cyrus-sasl-1.5.24-14 [root@mail2 SOURCES]# rpm -q db3 db3-devel db3-3.1.17-5 db3-devel-3.1.17-5 Help? -Darren
RFC/HOWTO: LDAP + SASL + Cyrus imapd (with SSL) + Postfix (with SMTP-AUTH)
Folks, A while back I was looking for Cyrus+Postfix best practice. See: http://msgs.SecurePoint.com/cgi-bin/get/postfix0012/336.html I've made some progress and am basically soliciting feedback on my approach thus far. In a previous life, my setup used SASL to manage both Cyrus imapd logins (mail checking) and postfix authenticated SMTP (mail sending). Both Cyrus and Postfix were happy enough sharing /etc/sasldb and authenticating clients using CRAM-MD5, and life was good. First wrinkle. Enter the need to centralize authentication using LDAP. *ugh* I can get Cyrus authenticating against LDAP using: sasl_pwcheck_method: pam and the appropriate additions to /etc/pam.d/imap, but I lose the ability to authenticate CRAM-MD5 and instead have to use plaintext logins. To address that, so that cleartext is never passed, I'll encrypt the entire IMAP protocol (and see if I can handle the compute overhead for long-term use while I'm at it). Using cyrus-2.0.11's imaps and OpenSSL I am now able to login to Cyrus over an ssl-encrypted wire, so bye-bye plaintext: Feb 19 22:24:39 mail2 imapd[28977]: login: somehost.some.org[###.###.##.##] dnickerson plaintext+TLS **PROBLEM** how the heck can I use authenticated SMTP with postfix in a secure manner now? As I understand it, I'd need to use SASL, which is regrettably passing plaintext around and postfix ain't talking SSL yet. Here's what I did. I put the following in imapd.conf: sasl_auto_transition: yes to populate /etc/sasldb directly from imapd logins. I used the following owner/group and modes on sasldb: [root@mail2 /etc]# ls -al sasldb -rw-r--r--1 cyrusroot12700 Feb 20 01:14 sasldb Next, to allow postfix to read this I had to take smtpd out of its chroot jail in master.conf: # == # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (50) # == smtpinetn - n - - smtpd To get smtpd to read sasldb I would have thought I would need something like: pwcheck_method:sasldb or sasl_pwcheck_method: sasldb in a file called /usr/lib/sasl/smtpd.conf (which is correct by the way?) Independent of which is the correct form, it seems to be unnecessary . . . even without a smtpd.conf file smtpd seems happy to grok sasldb. Perhaps this is the default? This approach seems to work fine for SMTP-AUTH. As a side effect, I also seem to have managed to get CRAM-MD5 working for imap logins . . . is this just a side effect of building up a sasldb? Feb 20 00:50:30 mail2 imapd[30023]: starttls: TLSv1 with cipher DES-CBC3-SHA (168/168 bits) no authentication Feb 20 00:50:30 mail2 imapd[30023]: login: somehost.some.org[###.###.##.##] dnickerson CRAM-MD5+TLS User logged in Well, I'm certainly not going to complain ;-) Here's the smtpd log: Feb 20 00:53:23 mail2 postfix/smtpd[30025]: 5BDC9EBC3B: client=somehost.some.org[###.###.##.##], sasl_method=CRAM-MD5, sasl_username=dnickerson Sweet. So I create a user, login once to imap with plaintext to populate sasldb with the appropriate secret, then switch to CRAM-MD5 forever after for both IMAP and SMTP-AUTH logins. And as an extra win, I've gone to the trouble of encrypting IMAP traffic so our "road warriors" won't be showing our inbound mail to the world. I'd welcome comments on anything I've missed in terms of recommended configuration, or security best-practice. I suppose the most glaring weakness of the current scheme is the cleartext nature of outbound SMTP traffic. Since postfix is not yet speaking ssl I'm not sure there's much to be done there aside from using something like stunnel/ssh to setup a port redirection. Anyone doing this? Thanks in advance for any comments. . . I hope this is helpful to someone! -Darren
Cyrus-2.0.7 + LDAP + CRAM-MD5 can never work, by definition?
Folks, I must be missing something obvious here . . . please can someone tell me how to get Cyrus to use LDAP for all types of authentication? I'm happily using PAM + LDAP for Cyrus authentication thanks to the following line in /etc/imapd.conf: sasl_pwcheck_method: pam and it's working fine with LOGIN authentication: [root@mail2 nss_ldap-122]# imtest -u someone -a someone -m LOGIN localhost C: C01 CAPABILITY S: * OK mail2.iworkwell.com Cyrus IMAP4 v2.0.7 server ready S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT MULTIAPPEND ID SORT THREAD=ORDEREDSUBJECT AUTH=GSSAPI AUTH=DIGEST-MD5 AUTH=CRAM-MD5 X-NETSCAPE S: C01 OK Completed Password: + go ahead L01 OK User logged in Authenticated. Security strength factor: 0 . logout I've jacked up slapd's logging, and I can see lots of activity when the authentication takes place. Unfortunately, if I switch to a CRAM-MD5 test, slapd is silent (no request is made) and the authentication fails with the following message: Dec 8 18:19:56 mail2 imapd[14340]: badlogin: mail2.iworkwell.com[127.0.0.1] CRAM-MD5 authentication failure [no secret in database] The following excerpt from sasl's sysadmin.html seems relevant: The PAM authentication for SASL only affects the plaintext authentication it does. It has no effect on the other mechanisms, so it is incorrect to try to use PAM to enforce additional restrictions beyond correct password on an application that uses SASL for authentication. Am I beating a dead horse here? Does authenticating against MySQL or LDAP using PAM by definition mean I'm limited to *shock horror* plaintext passwords? Say it ain't so!? Am I forced to interoperate with that nasty sasldb beast if I want to CRAM-MD5 my way through life? Thanks for any advice. -Darren
