Mark Crispin wrote:

...As a model, look at how the GETQUOTA command is implemented. That is, look at routine imap_getquota() to see how to send a command, and the processor for the QUOTA response (search for "this response has a bizarre syntax") to see how to field a response. You should be able to reuse existing parsing routines instead of having to write your own

Great, thanks Mark.


One final comment. The whole idea of PROXYAUTH has been obsolete for a decade, having been replaced with SASL authentication/authorization ID. Rather than implement a bad idea from the past, perhaps you should implement the modern, standard way of doing things. What's more, c-client already supports it without you having to do anything.

How do I generically support this feature with any given server a customer might be using? Some common servers used are Exchange [for some users - although in many cases they would just use our direct 'Exchange Connector'], CommuniGate Pro, SunOne, MiraPoint, and GroupWise. [Don't get me started on how much of a piece of junk GroupWise's IMAP implementation is, but I'm sure you already know that.]


If I could start using SASL 'authentication' support for administrative logins that are then authorized as user X (without us having to know user X's password) and it worked against a variety of IMAP implementations, that would be absolutely *fantastic*.
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. 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 "if the authentication method doesn't support the concept" (call me uninformed, but how would I know this?). Elsewhere, in naming.txt - the /authuser flag is mentioned. Which is it? xxx*yyy, or /authuser=xxx ? Either one?


The reality is as a company required to integrate with a variety of IMAP servers, we pretty much have to support this.

PROXYAUTH is not part of an IMAP server.

I'm aware of that, but it's part of an IMAP server extension which we added support for years ago and (presumably) need to continue to support. Admittedly, I haven't kept up-to-date with the various mail/imap RFC's as I implemented basic IMAP/SMTP/LDAP support for one of our mail connector pieces many years ago and it's basically been one of those things that has 'just worked' for quite some time. The features our servers need e-mail wise have been pretty straight-forward, so that's worked pretty well for a while. Recently though, some of our customers are needing to have their former 'internal-only' unified messaging servers be exposed to a larger 'outside' group, so SSL support in particular has quickly gone from 'nice-to-have' to a requirement. This is where c-client has come in. SSL support is basically a freebie. :)


Thanks for your help...
Patrick Bennett





Reply via email to