ID: 33500 Comment by: hmandel at learningbygrace dot org Reported By: ed2019 at columbia dot edu Status: Assigned Bug Type: Feature/Change Request Operating System: * PHP Version: 5.2.9 Assigned To: pajoye New Comment:
While you guys are debating whether this is a bug or a feature request our coders here are still stuck at the end of developing some web apps because PHP and Exchange will not "exchange"... Damn it Jim, we can't get our emails off the Exchange server.:~) So since I can see you have all this expertise and are fully aware of the bug/feature request, I'd like to hire one of you to make this change and customize our darn PHP code so these guys (PHP and Exchange) can make up and talk again. ANyone up to it. I'll hire you so long as you REALLY can solve the problem and also I will not discriminate between those who believe this is a Feature Request and those who call i a Bug... we are equal opportunity here at Learning By Grace. My contact info is hmandel at learningbygrace dot org. Cell is two67-two49-five one67. Any takers? Previous Comments: ------------------------------------------------------------------------ [2009-04-27 18:42:40] paj...@php.net ok, I was looking at mail_auth*. Then it should be possible to do it, I move the status to feature request (leaving it in the imap category but assigned to me, I will setup GSSAPI in my test exchange server box to valid the changes). Thanks for all the referecences, it will make the implementation easier. ------------------------------------------------------------------------ [2009-04-27 17:31:15] ed2019 at columbia dot edu pajoye - You're the one with the power to declare whether it's a bug or not. Since we disagree on this point, either I don't know what a bug is (entirely possible) or myself & the others commenting on this situation via the bug reporter have done a poor job of explaining to you what the situation is. To answer the included questions: "It could be a feature request but I do not see either how to you can force c-client to use a given authentication method. I suppose you know right?" Yes, you can force c-client to use / not use a particular authentication method. Please see this series of e-mail messages: http://www.mail-archive.com/imap...@u.washington.edu/msg01962.html http://www.mail-archive.com/imap...@u.washington.edu/msg01963.html "now, about your proposal: 1) why don't you try?" I did discuss the issue with Crispin, please see this exchange of e-mail messages: http://mailman2.u.washington.edu/pipermail/imap-uw/2005-June/000101.html Notably his response: "I agree that c-client should try the other authentication method, but perhaps my definition of "should" is different. I don't mean "should" as in "should be fixed to"; I mean "should" as "it does already." I believe that the problem is in how PHP uses c-client. " More questions: "2) and 3) are the same and I don't see how it could be possible. No other clients using c-client allow that either" For an example of an IMAP client, which uses c-client, and yet can attach to IMAP servers which advertise multiple authentication mechanisms please see Alpine ( http://www.washington.edu/alpine/ ) Here is a psudeo-psudeo-code examples of how it could be possible. I'm not a strong c-coder so I leave the actual implementation to the reader: * Add another optional arugment to the end of imap_open(), for example: imap_open(existing,argument,...,[NEW_ARUGMENT]) where: NEW_ARGUMENT is one or more, comma separated, of the following: GSSAPI, PLAIN, CRAM_MD5, etc (all the auth methods which c-client supports). Then, before a connection is attempted, the mail_parameters thing is set (as appears in Crispin's e-mail from 4/4/2008): mail_parameters (NIL,DISABLE_AUTHENTICATOR,(void *) "GSSAPI"); Again, I'm not a c-coder nor familiar with the code of imap_open, but that's at least one way to go about it. ------------------------------------------------------------------------ [2009-04-27 16:43:47] paj...@php.net There is no bug regarding this problem in php, like it or not. It could be a feature request but I do not see either how to you can force c-client to use a given authentication method. I suppose you know right? now, about your proposal: 1) why don't you try? 2) and 3) are the same and I don't see how it could be possible. No other clients using c-client allow that either ------------------------------------------------------------------------ [2009-04-27 16:09:36] ed2019 at columbia dot edu Hi again- In response to the reference to Joe's comment on the red hat bug list about how the c-client code stops retrying, my response is - so what? Many other applications built on top of c-client manage to authenticate via IMAP / PLAIN to these same servers. The key is that c-client already includes a mechanism for connecting to a server with multiple advertised methods - you can give it an argument and tell it which one to use. There are at least three ways to "fix" this bug: 1) Convince Mark Crispin (c-client's author) to modify c-client so that it tries all the advertised authentication methods. I.e. proclaim that it's not a PHP bug, that instead the library should be changed to work with imap_open's flaws. 2) Add an argument/flag/option to imap_open so that the programmer can specify the authentication method to try. I.e. Give the PHP developer access to more of the working functionality of the underlying library. 3) Modify PHP's imap_open() so that it will try multiple authentication methods. I understand that deciding that #1 is the "right answer" carries with it the additional benefit that no one needs to admit that this is a PHP bug. However, it's a bit ridiculous considering all of the other applications which depend on c-client and can handle authenticating to these servers. Please review like-minded comments from at least 5 other persons on this bug. I whole-heartedly encourage the maintainer to re-designate this as a real bug. ------------------------------------------------------------------------ [2009-04-27 15:54:06] ed2019 at columbia dot edu Hi- I was the original submitter of this bug four years ago, but I felt I should write to clear up a little confusion which has popped up from pajoye at php.net . Mark Crispin's c-client (which is the library underlying PHP's IMAP stuff) can authenticate to IMAP servers using various methods, including but not limited to PLAIN and GSSAPI. You can specify when calling the c-client library which authentication method to use. When you're going to authenticate with kerberos/GSSAPI, you would provide a certain set of client credentials. When you want to authenticate with PLAIN, you provide a different set of credentials (namely, username and password). The problem with PHP's imap_open() is that it does not allow you to specify which of these authentication methods to use, nor does it guess correctly from the credentials you provide it. The setup, as I encountered it, is/was: 1) Your code wants to authenticate to an IMAP server with a username & password. These credentials are appropriate for PLAIN authentication. 2) You call imap_open() and pass it the username & password. 3) imap_open() (through c-client) contacts the server attempts to authenticate via GSSAPI, which fails. imap_open() then gives up. So, the bug in this case is that imap_open needs an argument of some sort which tells it NOT to try using GSSAPI, and instead to try using PLAIN authentication. Perhaps something like [authmethod ={PLAIN || GSSAPI || ...}] , which would then be passed through to the c-client implementation. Make no mistake about it, there is no way around this bug with PHP's broken imap_open(). If you have an imap server which advertises both authentication methods, there is no way to authenticate to that server with the PLAIN method - even though the server is configured correctly, and the underlying c-client IMAP library supports it. imap_open() is not tickling the c-client library correctly to get the proper result. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33500 -- Edit this bug report at http://bugs.php.net/?id=33500&edit=1