What if I don't want to use GSSAPI?  I'm providing a username and password that should be sufficient for the PLAIN auth method.

Try to contact your system admintrator.
Questions related to IMAP server administration obviously do not belong to the PHP bug system. 

I am the system administrator.  I appreciate your trying to screen out non-bugs, but this is not a non-bug, but I am quite sure that this is a real bug.

An IMAP server supports multiple methods of remote client authentication.  Among them, GSSAPI and plain.  When a client connects, the server advertises these auth methods and other options it supports, for example, GSSAPI, PLAIN, etc.

The client then selects which AUTH method to use.  php's imap extension is choosing to use the GSSAPI method, but I would like it to make a different choice.  Or, after GSSAPI fails, I would like it to try the PLAIN auth method.

There is, however, no way (to my knowledge, or in the documentation) to get it to make that choice.  The underlying c-client library that php uses to talk to imap servers supports making the choice, and the imap servers themselves support it, but PHP does not.  I think that puts it into the category of a 'bug' that belongs in PHP's bug system.

I have also filed this bug with RedHat, see bug # 161826:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161826 , as well as to Mark Crispin ( author of the c-client imap library ), that discussion is archived here:
http://mailman1.u.washington.edu/pipermail/imap-uw/2005-June/000091.html

FYI, the same problem appears when trying to use plain-text POP3 authentication against a Microsoft Exchange 2007 server.

IMHO, this is indeed a deficiency in PHP, and the solution is simple: Expose the uw-imap mail_parameters() function in the PHP API.

This issue is also in PHP5 ... there's no way to open an imap/pop connection to an exchange2007 server that announces GSSAPI :-(

If you happen to run across this error while attempting to connect to an Exchange server.......  In my case Exchange 2007 from Ubuntu

Install Kerberos client i.e heimdal-client

Switch to the apache user....for Ubuntu that is "www-data":

su www-data

kinit username@DOMAINNAME.COM 'Mind the case lower@UPPER

klist 'Will show current ticket granting ticket and other tokens

Note: krbtgt will expire and this procedure will need to be repeated I am currently researching a method to ensure an active krbtgt at all times

Try testing with this script as the apache user, replacing ipaddress, username, domainname and password.

<?php
$mbox = imap_open("{ipaddress:993/imap/ssl/novalidate-cert/notls/debug}INBOX", "domainname/username", "password") or die(imap_last_error()."<br>Connection Failure!");

echo "<h1>Mailboxes</h1>\n";
$folders = imap_listmailbox($mbox, "{ipaddress:993}", "*");

if ($folders == false) {
    echo "Call failed<br />\n";
} else {
    foreach ($folders as $val) {
        echo $val . "<br />\n";
    }
}

echo "<h1>Headers in INBOX</h1>\n";
$headers = imap_headers($mbox);

if ($headers == false) {
    echo "Call failed<br />\n";
} else {
    foreach ($headers as $val) {
        echo $val . "<br />\n";
    }
}

imap_close($mbox);
?>

Hello,

this problem still exists in PHP 5.2.6. As stated by Mark Crispin [1] this problem is probably a bug in the PHP IMAP implementation. Any suggestions how to fix this problem?

Regards,
Benjamin

[1] http://mailman2.u.washington.edu/pipermail/imap-uw/2005-June/000101.html

imap_open() absolutely needs a way to specify the order of authentication mechanisms to try. If one is attempting to do username/password auth to an imap server that supports GSSAPI, imap_open() tries GSSAPI then stops, never attempting to do PLAIN auth or otherwise. 

This should not be viewed as a misconfiguration of the imap server, as clients that use c-client manage to try multiple auth mechs.

Bug still present, 5.2.8, Centos 5.2.

I can't connect to Exchange 2007 sp1
PHP running on Windows 2000
C:\php>php -v
PHP 5.2.8 (cli) (built: Dec  8 2008 19:31:23)

with Pear Net_POP3         1.3.6   stable

example from getMessage() after logon...

      Error in authentication: USER NOT supported authentication method!. This server supports these methods: GSSAPI, but I support APO
P,PLAIN,LOGIN,USER

Please PHP developers, fix this bug since there are no other elegant methods to connect Exchange 2007 than imap_open. Implement authentication method attribute to IMAP_OPEN or make it automatically use multiple methods.

Same bug, on version 5.2.0 (Debian/stable), when trying to connect to Exchange.

The authentication method is compiled in cclient. Are you sure your cclient package supports kerberos or GSS?

For windows, I'm verifying that it works with 5.3.0 (we use the latest c-client for 5.3+).

Bug or feature in c-client. As Joe already explained in the RH bug report, the first thing auth_gssapi_client does is to disable any retry:

auth_gss.c:98 (2007e)
  *trial = 65535;		/* never retry */

Please get an explanation in the UW mailing list but there is nothing PHP can do about that.

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.

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.

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

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-uw@u.washington.edu/msg01962.html
http://www.mail-archive.com/imap-uw@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.

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.

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?

It is a feature request, if you read our last two comments you will see that we already agreed on that. 

I'm running Group-Office and I have this same problem. I can get it to login to our Exchange 2007 server by running `kinit username@DOMAIN.COM` on Apache's user. However, this causes all the Group-Office mail accounts to receive that user's emails, regardless of the credentials given to them. From my understanding, it is not technically incorrect to use c-client the way PHP currently does, but it is inefficient and limits the developers possibilities. So, it's been over a month since this request was updated. Is there any news on the status of this issue? Pajoye, if you can fix this, you will be my personal hero, and I'll name something after you. ;)

Yes, have the patch but it was too late for 5.3.0. It will be committed in HEAD and after 5.3.1.

I had a similar problem, which I thought was caused by this bug/lack of feature, but was solved by a comment I found at the PHP manual's function description of imap_open. It merely required me to add '/user=' to the end of my list of protocols. I'm not sure whether this directly relates to this problem, but I hope it helps someone.

any ETA of when this will be checked into SVN (and what files to pull)?  We have run into this exact problem when we upgraded to Exchange 2007.

Please try this patch: http://pierre.libgd.org/patches/bug33500.txt (against PHP 5.3). It adds a parameter option to imap_open. For now only 'DISABLE_AUTHENTICATOR' is supported. Example usages:

$im = imap_open($hostname, $username, $password, NULL, 1, array('DISABLE_AUTHENTICATOR' => array('GSSAPI', 'NTLM')));


$im = imap_open($hostname, $username, $password, NULL, 1, array('DISABLE_AUTHENTICATOR' => 'NTLM'));

To disable respectively GSSAPI and NTLM or only NTLM.

I have tried the patch and keep getting the error:

Warning: Wrong parameter count for imap_open()

I am using Ubuntu 9.04 and am compiling against the php 5.3.0 source with the associated patch applied and with the 

./configure --with-imap --with-kerberos --with-imap-ssl 

initial command, make clean;make all;make install is the next commands I execute.

I have also tried the source 5.3.1RC2 and this gives the error:

Warning: imap_open() expects at most 5 parameters, 6 given

If someone has managed to get this to work please provide a copy of the binaries until the release is rolled out to apt.

Am I missing something here?

Best Regards,
Bill

It sounds like the patch was not applied then. It clearly takes 3 or 6 parameters:
+	if (zend_parse_parameters(argc TSRMLS_CC, "sss|lla", &mailbox, &mailbox_len, &user, &user_len,
+		&passwd, &passwd_len, &flags, &retries, &params) == FAILURE) {

Can you verify that the patch was actually applied?

It looks like you may have forgotten to add the following to your patch:

Index: php_imap.c
===================================================================
--- php_imap.c        (revision 3434)
+++ php_imap.c        (working copy)
@@ -105,6 +105,7 @@
ZEND_BEGIN_ARG_INFO_EX(arginfo_imap_open, 0, 0, 3)
       ZEND_ARG_INFO(0, mailbox)
       ZEND_ARG_INFO(0, user)
       ZEND_ARG_INFO(0, password)
       ZEND_ARG_INFO(0, options)
       ZEND_ARG_INFO(0, n_retries)
+      ZEND_ARG_INFO(0, params)
ZEND_END_ARG_INFO()

This should allow for a max of 6 arguments instead of just 5.

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.