php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #78572 Discontinue use of c-client library
Submitted: 2019-09-20 03:07 UTC Modified: 2024-07-24 00:19 UTC
Votes:7
Avg. Score:4.1 ± 1.5
Reproduced:4 of 5 (80.0%)
Same Version:3 (75.0%)
Same OS:2 (50.0%)
From: bishop@php.net Assigned: petk (profile)
Status: Closed Package: IMAP related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: bishop@php.net
New email:
PHP Version: OS:

 

 [2019-09-20 03:07 UTC] bishop@php.net
Description:
------------
The IMAP extension does not perform as well as pure user-land implementations of the IMAP protocol. This is due, in largest part, to the c-client library on which this extension's based: c-client is many years unmaintained and there are numerous bugs related to it.

Scope of this ticket is to formulate a remediation plan, where we can either replace c-client with a similar, maintained library or implement the IMAP protocol ourselves natively. This is essentially a reboot of the IMAP extension and would require, I believe, extensive work to accomplish.

An alternative is to sunset the extension, encouraging consumers to switch to a pure PHP extension.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-09-20 03:11 UTC] bishop@php.net
See also https://externals.io/message/103464
 [2019-09-20 03:12 UTC] bugreports at gmail dot com
problem is that there is no userland implementation i know of which supports POP3 the same way which is interesting when you have a testing mailserver with all sort of previously problem messages burried in a autotest to make sure they are reconstructed identically with IMAP/POP3 and at least here we heave a large amount of POP3 users
 [2019-09-20 04:57 UTC] bishop@php.net
Thanks for mentioning POP3 support, bugreports@gmail.com. No matter what happens, we'd not abandon POP3 support.

If we sunset the PHP IMAP extension, then we'd recommend consumers update their applications to use a robust, IMAP and POP3 capable library. For example, Horde/Imap_Client[1] supports POP3[2], is fast, well-tested, and extensible.

If we choose to reboot the extension, when we'd have to make it support IMAP and POP3.

[1]:https://dev.horde.org/imap_client/
[2]:https://github.com/horde/Imap_Client/blob/master/doc/Horde/Imap/Client/examples/tutorial.md
 [2019-09-20 07:45 UTC] kalle@php.net
Note, I'm not super familiar with c-client anymore.

What would the technical cost and depth be to implement it in C, as our own library? Would it be sufficient to do so or would it be an overkill? The reason I'm asking is primarily that imap is a popular extension and it has been for a very long time, I personally would be sad to see it go, but if the grounds is that there is no otherwise stable backend to base it on, then I can agree on those merits that it should go.
 [2019-09-20 07:50 UTC] nikic@php.net
Providing a composer package that exposes the ext/imap API on top of some existing IMAP implementation is the way forward here, IMHO.

A native implementation of the IMAP protocol is a strong no-go from me. There is no benefit to implementing this in C, and lots of disadvantages, especially where it comes to security.
 [2019-09-20 09:29 UTC] cmb@php.net
I fully agree with Nikita.

The current show-stopper appears to be mail related tests on
Windows, which currently use ext/imap.
 [2019-11-05 20:42 UTC] toddr at cpanel dot net
FYI Imap-2007 will no longer compile on RedHat 8.
 [2019-11-05 20:45 UTC] ghghghghghgh at netflix dot com
> FYI Imap-2007 will no longer compile on RedHat 8

i doubt that RHEL has anything newer than Fedora 31 where it works depsipte of httpd crahes when you relod apache instead of a hard restart

it's not nice *but* there is *no* replacement in case someone drives serious IT and autotests to compare behavior if IMAP *and* POP3 for the same messages
 [2019-11-05 23:52 UTC] girgias@php.net
Related to Bug #78783
 [2019-12-31 17:37 UTC] kieran at miami-nice dot co dot uk
I agree with Nikita.

RE: sunset. I don't think there's a great deal wrong with ext/imap to warrant that. That said, it's long been neglected and if the world is moving towards OAuth then I'm sure the PHP devs would vote to drop it.

For me, I think I'll consider moving to Horde/Imap_Client. The key benefit being that it's well tested. Anything that comes out of this ticket is likely to be rushed and buggy, or not available before the deadlines set by Google & Microsoft. 

Is anyone aware of any progress on anything?
 [2020-01-08 05:34 UTC] bishop@php.net
Relates to: Bug 64039
 [2020-01-08 05:38 UTC] bishop@php.net
I agree with Nikita, too. If we were to write a native implementation, we'd effectively become a library implementation of IMAP for others: I'm for that altruistically, but don't have the bandwidth to do so.

I also agree with Kalle, imap is a popular extension and would hate to see it go. I'm not for deprecating it.

I believe the best plan for now is to keep the lights on: fix bugs and add small new features as required by the march of technology (eg Bug 64039), but also curate a catalog of user-land implementations that may fit particular use cases better.
 [2023-04-06 09:39 UTC] mikejohmarizonsd at gmail dot com
Get Post Daily are sharing latest news about auto, tech, travel, education, home improvement, health etc. More info to visit:(https://getpostdaily.com)github.com
 [2024-07-24 00:19 UTC] petk@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: petk
 [2024-07-24 00:19 UTC] petk@php.net
Hello, the imap extension has been unbundled and moved to PECL https://github.com/php/pecl-mail-imap as a standalone extension with the upcoming PHP 8.4.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 10 07:01:28 2024 UTC