--On Wednesday, November 07, 2001 04:36:59 PM -0500 Lawrence Greenfield <[EMAIL PROTECTED]> wrote:
> [...] > That fixed the DIGEST-MD5 problem; but it seems to have broken PLAIN. > Now DIGEST-MD5, CRAM-MD5, and LOGIN all work; but PLAIN returns: > > S: A01 NO bad protocol / cancel > > I don't know why this is happening, sorry. We don't use PLAIN on our > IMSP server. I prefer not to as well; and advise all users to use one of the MD5 methods. But I'd also like to support the widest range of potential clients; which means leaving PLAIN available. Also, it isn't unreasonable to use it with websieve or similar interface when the web server and the timsieved are running on the same host. (Although I admit I'd prefer to have a unix socket option for that case...) Unless you have PLAIN disabled, you should still be able to test it using imtest. > I'd also like to point out a minor deficency with the build process. > The FreeBSD port for cyrus-sasl puts libsasl.* in /usr/local/lib/ > and the header files in /usr/local/include/sasl/ Either I'm being > a bit thick or the configure script doesn't seem to be able to handle > that. (I just hacked the generated Makefiles to get it to build.) > [ Note: This was also true of the 1.6a3 tarball. ] > > env CPPFLAGS=-I/usr/local/lib LDFLAGS=-L/usr/local/lib ./configure ... I'll give it a try; but I suspect I'd have to make the CPPFLAGS option -I/usr/local/include/sieve or possibly list both the include and include/sieve dire. Setting environment variables is a pretty ugly way to force configure to work. The --with-sieve option -almost- works. Separate --with-sieve-includes and --with-sieve-lib options should be fairly easy to do; and would provide more flexability. And you could even keep the --with-sieve option and make the other two default to values based on the --with-sieve value. (Of course it would be better yet if it could just find the libraries and includes in those locations...) > [...] > And on a mostly unrelated note, what is the current state of the > ACAP daemon? Is it sufficiently featureful and stable to be > deployed in a small production environment? If I want to test > it out, should I go with the latest tarball, or get it from CVS? > > We don't recommend deploying ACAP; it seems unlikely to attract much > client implementation at this point. Isn't that sort of a vicious circle though? Don't bother to deploy it because there isn't much client support because it isn't widely deployed... Or are you saying that it's just too early in the development cycle? Or is there some other reason why clients aren't likely to support it? -Pat
msg04409/pgp00000.pgp
Description: PGP signature
