Re: How do I send custom IMAP commands with c-client ?
Mark Crispin wrote:
On Thu, 27 Jan 2005, Patrick Bennett wrote:
How do I generically support this feature with any given server a
customer might be using?
When you open the mailbox, use the /authuser= option, e.g.
{imap.example.com/user=fred/authuser=joe}inbox
where fred is the account to be logged into and joe is the
administrator account.
Yes, I tried exactly this.
...Did you use /authuser=, or did you try to use the * hack? Don't
try to use the * hack. It's only supported by the UW IMAP server,
and only for ancient clients that can't do SASL.
I tried both actually. When using /authuser with Exchange I get the
error 'Can't do /authuser with this server.' I would assume this is
simply because Exchange 2003 only supports AUTH=NTLM *grumble* and in
fact, when connected via SSL, it doesn't advertise any AUTH method at
all!? (which seems odd to me)
I then set up a local test CommuniGate Pro server to try it. Using
mtest (with debug protocol on - and the sensitive flags in imap41.c
disabled) I get this:
-
Mailbox ('?' for help):
{localhost/user=postmaster/authuser=patrickb/novalidate-cert}inbox
[Trying IP address [127.0.0.1]]
* OK CommuniGate Pro IMAP Server 4.2.8 at test1 ready
[CommuniGate Pro IMAP Server 4.2.8 at test1 ready]
CAPABILITY
* CAPABILITY IMAP4 IMAP4REV1 ACL NAMESPACE UIDPLUS IDLE LITERAL+ QUOTA
ID MULTIAPPEND LISTEXT CHILDR
EN BINARY LOGIN-REFERRALS STARTTLS AUTH=LOGIN AUTH=PLAIN AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=MSN
OK completed
0001 STARTTLS
0001 OK begin TLS negotiation
0002 CAPABILITY
* CAPABILITY IMAP4 IMAP4REV1 ACL NAMESPACE UIDPLUS IDLE LITERAL+ QUOTA
ID MULTIAPPEND LISTEXT CHILDR
EN BINARY LOGIN-REFERRALS AUTH=LOGIN AUTH=PLAIN AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=MSN
0002 OK completed
0003 AUTHENTICATE PLAIN
+
{localhost/imap/user=postmaster} password:
cG9zdG1hc3RlcgBwYXRyaWNrYgAxMjM0
0003 NO SASL parameters are incorrect
%Retrying PLAIN authentication after SASL parameters are incorrect
0004 AUTHENTICATE PLAIN
+
{localhost/imap/user=postmaster} password:
--
...any ideas?
Thanks,
Patrick Bennett
Re: How do I send custom IMAP commands with c-client ?
On Fri, 28 Jan 2005, Patrick Bennett wrote: When using /authuser with Exchange I get the error 'Can't do /authuser with this server.' As you surmised, Exchange does not support it. I then set up a local test CommuniGate Pro server to try it. Your test shows that Communigate Pro doesn't support it either; or at least you attempted to use an id that did not have administrative privileges. These are server issues. If it isn't supported in the server, there is no way that a client can offer the facility. At least, unlike PROXYAUTH, you can ask the server vendors to support it and point to an RFC which describes it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: How do I send custom IMAP commands with c-client ?
On Thu, 27 Jan 2005, Patrick Bennett wrote:
One final comment. The whole idea of PROXYAUTH has been obsolete for a
decade, having been replaced with SASL authentication/authorization ID.
How do I generically support this feature with any given server a customer
might be using?
When you open the mailbox, use the /authuser= option, e.g.
{imap.example.com/user=fred/authuser=joe}inbox
where fred is the account to be logged into and joe is the
administrator account.
This is documented in naming.txt.
However, I have to say it's not particularly clear how to do it, since my two
tests to use it (using mtest) against Exchange and Communigate Pro failed.
Did you use /authuser=, or did you try to use the * hack?
There's also almost zero documentation about it. The only mention I saw was
in RELNOTES and it said to use an * in the userid to seperate the identity
Don't try to use the * hack. It's only supported by the UW IMAP
server, and only for ancient clients that can't do SASL.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
