Support XOAUTH2 for authenticating against Gmail

[rikvdh]

Hi,

This is a solution for the XOAUTH2 authentication in the imap extension. I've extended the c-client library with a new authenticator which enabled support for XOAUTH2. (see https://bugs.php.net/bug.php?id=64039)

I have not written tests nor put it in to a separate file. I am willing to help further on this subject, but needs some pointing in the right direction for this.

To test this, you add the /secure flag and put the auth-string in the username. Password can be left empty.
For generating the access-tokens please look at the Google documentation. I can provide examples for that when required.

<?php
$ret = imap_open(
    '{imap.gmail.com:993/imap/ssl/validate-cert/secure}',
    sprintf("user=%s\1auth=Bearer %s\1\1", '[email protected]', $accessToken),
    ''
);

[cmb69]

First, thank you for the PR!

However, the README of this repo states:

This extension is no longer actively maintained or supported, and this repository serves as an archive for it.

So I'm not quite sure what to do. :/

[rikvdh]

I'm also not sure. I was hoping that someone else could have picked it up. We previously relied upon laminas/laminas-mail, but this is now abandoned and point to ddeboer/imap for inbound mailing with IMAP (which is based on php-imap). But as we work with Google Workspace we are forced to use XOAUTH2 which required a code change to work.

I've also read the 'no longer actively maintained'. But as a lot of people rely on this extension I think it deserves some attention.

I found this to be the 'least intrusive' change to facilitate this. If something else is needed, like some tests or whatever, please give me some pointers. I'm definitely not new to C and all it beholds. But PHP-extensions is a new one for me.

[GerardEarley]

I'm also not sure. I was hoping that someone else could have picked it up. We previously relied upon laminas/laminas-mail, but this is now abandoned and point to ddeboer/imap for inbound mailing with IMAP (which is based on php-imap). But as we work with Google Workspace we are forced to use XOAUTH2 which required a code change to work.

I've also read the 'no longer actively maintained'. But as a lot of people rely on this extension I think it deserves some attention.

I found this to be the 'least intrusive' change to facilitate this. If something else is needed, like some tests or whatever, please give me some pointers. I'm definitely not new to C and all it beholds. But PHP-extensions is a new one for me.

Thanks for contributing to the pecl-mail-imap, if you've an instructions on getting the extension building on a modern linux OS please post them somewhere. I'm running fedora and getting it to build is beyond the time and effort I can dedicate to it.

[cmb69]

See https://discussion.fedoraproject.org/t/how-to-install-php-imap-for-fedora-39/95930/2.

We previously relied upon laminas/laminas-mail, but this is now abandoned and point to ddeboer/imap for inbound mailing with IMAP (which is based on php-imap).

And we're back to square one. :(

See also #12 (comment) ff.

[remicollet]

I'm running fedora and getting it to build is beyond the time and effort I can dedicate to it.

Simply try https://rpms.remirepo.net/wizard/ ;)

BTW, still a dead project, so imap ext is provided in my repo for legacy app. Pure PHP library should be preferred for new project.

[GerardEarley]

I'm running fedora and getting it to build is beyond the time and effort I can dedicate to it.

Simply try https://rpms.remirepo.net/wizard/ ;)

BTW, still a dead project, so imap ext is provided in my repo for legacy app. Pure PHP library should be preferred for new project.

When @remicollet himself replies I tend to pay attention but unf your wonderful repository only supports the imap extension up to php 8.3 an not 8.4 😟 TBH I dont know if there is that much of a performance penalty in using a pure PHP library but it would almost certainly take less memory, atta guess. On older machines that would be rather a limit for me.

[cmb69]

I dont know if there is that much of a performance penalty in using a pure PHP library but it would almost certainly take less memory, atta guess.

Might be worth an actual measurement. :)

[rikvdh]

And we're back to square one. :(

It also feels like a step back.. While building this PR, browsing through c-client feels 'ancient' to say the least. I've also seen several possibilities there we probably some memory management was not done correctly..

I dont know if there is that much of a performance penalty in using a pure PHP library but it would almost certainly take less memory, atta guess.

Might be worth an actual measurement. :)

I don't care about performance tbh. Most IMAP-interaction is never in user-facing code anyway. After digging through c-client, I would also advice against using php-imap in user-facing stuff.

For the future, as there is no real 'major replacement' for php-imap AFAIK. laminas-mail is dead, php-imap is then considered 'dead end' (which on one hand, I understand).
But what else is out there? Moving away from 'doing anything with IMAP in PHP'?

[remicollet]

When @remicollet himself replies I tend to pay attention but unf your wonderful repository only supports the imap extension up to php 8.3 an not 8.4 😟

Sorry, you're wrong.

• php-imap available for PHP <= 8.3
• php-pecl-imap available for php >= 8.4
• dnf install php-imap works everywhere

[cmb69]

But what else is out there?

See #12 (comment) (I never even tried to use these packages, though).

[GerardEarley]

When @remicollet himself replies I tend to pay attention but unf your wonderful repository only supports the imap extension up to php 8.3 an not 8.4 😟

Sorry, you're wrong.

* php-imap available for PHP <= 8.3

* php-pecl-imap available for php >= 8.4

* `dnf install php-imap `works everywhere

Thanks @remicollet. For complicated reasons I have to compile my php-8.4 packages onsite and until today I'd not found the suitable rpm for the php-pecl-imap extension, until today and it compiles like a dream.

Thanks again for all you do. I'll donate again next pay day 👍

The php-pecl-imap src.rpm package I found was on.
https://rpms.remirepo.net/SRPMS/

[rikvdh]

But what else is out there?

See #12 (comment) (I never even tried to use these packages, though).

But what is still actively maintained? zetacomponents/Mail last release is 5 years ago.. horde/Imap_Client also feels a step back in time.

I've also thought about replacing c-client. But in C there is not much 'modern actively maintained' IMAP Clients available. I would guess that a pure PHP implementation would be the best way to go forward. I'll check how much work a 'php-imap compatible pure PHP' implementation would behold.

But for this PR, do you and would you accept PR's for this and consider publishing? Otherwise, deprecating the php-imap might be a better solution. Because people will otherwise continue to rely on this.

[rikvdh]

Ok, after a lot of searching around on the internet I found that there is still some maintenance on c-client nowadays as part of alpinemail (https://github.com/alpinemail/alpine/tree/master/imap/src/c-client). But using that might be not very well suited for the future. Maybe is trying to keep 'php-imap' alive a stretch in general and maybe instead of 'no active development', it should become 'deprecated'?

Making something compatible is not very interesting. A lot of different people are already building their own 'imap' clients. Having a definitive 'route' for the future would at least rule out some options.

Currently people are still switching to 'php-imap'-built solutions while some php-imap based libraries are still maintained.

Some other options I found for non php-imap based imap clients:
https://github.com/Webklex/php-imap
https://github.com/DirectoryTree/ImapEngine
https://github.com/javanile/php-imap2

And putting these here for complete reference from the before mentioned one:
https://github.com/horde/Imap_Client
https://github.com/zetacomponents/Mail

Previously I would list Laminas-mail here, but as that is abandoned I won't.
From my opinion we need a clear understanding what the future for php-imap will be in order to make a decision on how to go forward. It's ok to go without php-imap, but then so are all 'php-imap' based libraries (or they need to switch). At least then we know how to go forward. It now feels like a bleeding wound, because in a few years more and more distro's will abandon this as c-client will not work/compile correctly and it might become and exotic. If 'php-imap' is not dropped, development needs to continue in order to 'keep up'.

[NattyNarwhal]

It's worth reading the discussion in #3.

[rikvdh]

Thanks. That clears a lot up for me. My original point still remains.

Would patches be accepted or should we consider php-imap "deprecated and removed in php9/10/..."

Also, the suggestion for a client by @cmb69 in #3 is based on php-imap.

[cmb69]

I think the imap extension has to be considered obsolete. It can't really be removed in an upcoming PHP major version, since it has already been unbundled, and anybody can do with it what they like (assuming the license is adhered to). Therefore a deprecation doesn't make much sense (besides the technical challenge of deprecating an extension; could likely only deprecate the functions and constants).

[rikvdh]

perhaps https://www.php.net/manual/en/ref.imap.php and the functions should get updated then to reflect this obsolescence. That way it is clear for everyone (users of php-imap and php-src developers) that we need to move over to a different implementation and abandon php-imap in some respective timeframe.

[Tachi107]

XOAUTH2 isn't standard, and GMail supports OAUTHBEARER as well. Wouldn't it make more sense to use that instead of preferring XOAUTH2?

* OK Gimap ready for requests from 128.116.123.18 5b1f17b1804b1-45b4b262c5bmb646169815e9
A001 CAPABILITY
* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER

[rikvdh]

I think OAUTHBEARER will also require a change in php-imap. Since the dialogue above, If you need it you are probably better of going to a pure PHP-IMAP implementation (which there are plenty of) or use something else. New features will probably not be added to php-imap.

I'd vouch for obsoleting/deprecating php-imap. But I'm no party in this verdict. Since the underlying C-library is not really something well maintained and also maybe 'too complex network interfacing' to keep inside a php-extension.

[cmb69]

See https://www.php.net/manual/en/intro.imap.php; the extension is already officially deprecated.