Req #78572 [Com]: Discontinue use of c-client library

From: Date: Tue, 05 Nov 2019 20:42:59 +0000
Subject: Req #78572 [Com]: Discontinue use of c-client library
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-223588@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=78572&edit=1

 ID:                 78572
 Comment by:         toddr at cpanel dot net
 Reported by:        bishop@php.net
 Summary:            Discontinue use of c-client library
 Status:             Open
 Type:               Feature/Change Request
 Package:            IMAP related
 PHP Version:        Irrelevant
 Block user comment: N
 Private report:     N

 New Comment:

FYI Imap-2007 will no longer compile on RedHat 8.


Previous Comments:
------------------------------------------------------------------------
[2019-09-20 09:29:31] 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-09-20 07:50:13] 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 07:45:39] 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 04:57:30] 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 03:12:15] 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

------------------------------------------------------------------------


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

    https://bugs.php.net/bug.php?id=78572


--
Edit this bug report at https://bugs.php.net/bug.php?id=78572&edit=1


Thread (15 messages)

« previous php.bugs (#223588) next »