In the meantime, I solved this by patching imapd.c thanks to Rich Graves who sent this 3-line insert patch which allows plain text from localhost:
<x-tad-bigger>*** imapd.c.orig Wed Jan 28 12:00:35 2004
--- imapd.c Fri Dec 31 13:05:49 2004
***************
*** 264,269 ****
--- 264,274 ----
/* initialize server */
server_init(pgmname,"imap","imaps",clkint,kodint,hupint,trmint);
/* forbid automatic untagged expunge */
+
+ if (strstr(tcp_clienthost (),"127.0.0.1") != NULL) {
+ mail_parameters(NIL,SET_DISABLEPLAINTEXT,NIL);
+ }
+
mail_parameters (NIL,SET_EXPUNGEATPING,NIL);
/* arm proxy copy callback */
mail_parameters (NIL,SET_MAILPROXYCOPY,(void *) proxycopy);
</x-tad-bigger>
(Also, FWIW, the second part of my initial email about plaintext authentication failure was simply due to my oversight: I had forgotten that the make target was "oxp" not "osx".)
Happy New Year,
-d
On Jan 2, 2005, at 7:43 AM, Chris Bunch wrote:
--On Friday, December 31, 2004 12:06 am -0500 David Kulp
<[EMAIL PROTECTED]> wrote:
[ My apologies in advance for a query that has probably been hashedDavid -
repeatedly, but a search of the c-client archives revealed nothing. ]
I have been running imapd on OS X for about a year using SSL (standard
build). I would like to configure imapd to allow plaintext logins for
clients from the localhost, but refuse plaintext otherwise. My
motivation is that I want to provide a webmail client, but none of the
clients that I've investigated (SquirrelMail, IlohaMail, etc.) support
SSL. Since the http and mail server are on the same host and the web
client is connecting via https, then IMAP/SSL is unnecessary anyway.
Does anyone have a recommendation for such a configuration?
Second, assuming that I must allow plaintext, I attempted to build a
working imapd with plaintext support. I did makes with both ssltype=unix
and ssltype=none. In either case, AUTHENTICATE LOGIN fails. Again,
authentication works fine for SSL (AUTHENTICATE PLAIN). I don't
understand the difference between LOGIN and PLAIN authentication, but I
couldn't find an explanation in rfc2222 (SASL) or rfc3501 (IMAP4).
I suspect that this might have something to do with pam, but I'm not sure
where to turn.
Any advice would be most appreciated.
Thanks in advance,
David
I am running SquirrelMail and imapd on the same OS X (Panther) machine. I
have imapd compiled with
make osx SSLTYPE=unix
which will allow plaintext passwords with port 143 connections as well as
encrypted passwords via SSL on 993. I set my external firewall to block any
incoming port 143 requests so external user must use SSL.
Some other notes from my log:
There is a good description on setting this up at
<http://www.macdevcenter.com/pub/a/mac/2002/08/23/jaguar_server.html?page=last&offset=101>
Always do a 'make clean' if you need to recompile for any reason
You will need to configure inetd for both imap4 and imaps
For some reason impad expects SSLCert imapd.pem to be in
/System/Library/OpenSSL/certs/
I have written about setting up SquirrelMail at
<http://jambalaya.bayswaterfarm.com/archives/000030.html>
hth
C
__________________________
Dis aliter visum
http://jambalaya.bayswaterfarm.com
--On Friday, December 31, 2004 12:06 am -0500 David Kulp
<[EMAIL PROTECTED]> wrote:
[ My apologies in advance for a query that has probably been hashed
repeatedly, but a search of the c-client archives revealed nothing. ]
I have been running imapd on OS X for about a year using SSL (standard
build). I would like to configure imapd to allow plaintext logins for
clients from the localhost, but refuse plaintext otherwise. My
motivation is that I want to provide a webmail client, but none of the
clients that I've investigated (SquirrelMail, IlohaMail, etc.) support
SSL. Since the http and mail server are on the same host and the web
client is connecting via https, then IMAP/SSL is unnecessary anyway.
Does anyone have a recommendation for such a configuration?
Second, assuming that I must allow plaintext, I attempted to build a
working imapd with plaintext support. I did makes with both ssltype=unix
and ssltype=none. In either case, AUTHENTICATE LOGIN fails. Again,
authentication works fine for SSL (AUTHENTICATE PLAIN). I don't
understand the difference between LOGIN and PLAIN authentication, but I
couldn't find an explanation in rfc2222 (SASL) or rfc3501 (IMAP4).
I suspect that this might have something to do with pam, but I'm not sure
where to turn.
Any advice would be most appreciated.
Thanks in advance,
David
== mtest with SSLTYPE=none ==
./mtest
MTest -- C client test program
warning: this program uses gets(), which is unsafe.
Personal name:
Debug protocol (y/n)?y
Mailbox ('?' for help): {localhost/user=jsmith}inbox
[Trying IP address [127.0.0.1]]
* OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS AUTH=LOGIN]
localhost IMAP4rev1 2003.347 at Thu, 30 Dec 2004 23:26:08 -0500 (EST)
00000000 AUTHENTICATE LOGIN
+ VXNlciBOYW1lAA==
{localhost/imap/user="jsmith"} password:
<suppressed>
+ UGFzc3dvcmQA
<suppressed>
00000000 NO AUTHENTICATE LOGIN failed
== mtest with default SSL ==
./mtest
MTest -- C client test program
warning: this program uses gets(), which is unsafe.
Personal name:
Debug protocol (y/n)?y
Mailbox ('?' for help): {localhost/user=jsmith/novalidate-cert}inbox
[Trying IP address [127.0.0.1]]
* OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS STARTTLS
LOGINDISABLED] localhost IMAP4rev1 2003.347 at Thu, 30 Dec 2004 23:41:56
-0500 (EST)
00000000 STARTTLS
00000000 OK STARTTLS completed
00000001 CAPABILITY
* CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE MAILBOX-REFERRALS BINARY
UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND
SASL-IR LOGIN-REFERRALS AUTH=PLAIN AUTH=LOGIN
00000001 OK CAPABILITY completed
00000002 AUTHENTICATE PLAIN
+
{localhost/imap/user="jsmith"} password:
<suppressed>
00000002 OK [CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE
MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES
THREAD=ORDEREDSUBJECT MULTIAPPEND] User jsmith authenticated
--
------------------------------------------------------------------
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------
