# Alternative c-client

- Thread: https://externals.io/message/73003
- Original archive: https://news-web.php.net/php.internals/73003
- Started by Pierre Joye on 2014-03-08T07:20:45+00:00
- Messages: 6
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #73003 — Pierre Joye — 2014-03-08T07:20:45+00:00

URL: https://externals.io/message/73003#73003

hi,

We have discussed the possibility or need to drop ext/imap support, as
the c-client (or the whole UW project) is dead and full of security
issues.

As an alternative, I found https://github.com/jonabbey/panda-imap,
which is maintained, open to PRs, etc.

It would be nice if we could give it a try and see if we can consider
it as a replacement for c-client and require it from now on. Or we
simply drop ext/imap in 6.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #73034 — Matt Ficken — 2014-03-09T22:39:26+00:00

URL: https://externals.io/message/73003#73034 · In reply to: #73003

The current imap c-client has some major blocking bugs, and since its
dead/abandoned it should be removed.

Since PHP can send email it should be able to receive email too, and IMAP >
POPn.


The larger question is what to replace it with?

I have had good experience with the Net_IMAP PEAR package. Its PHP code so
if there is an interoperability problem with a particular IMAP server
(which is more common problem than with SMTP servers), users can fix it (I
found that useful myself). Unfortunately for inclusion in core, its not c.




> hi,
>
> We have discussed the possibility or need to drop ext/imap support, as
> the c-client (or the whole UW project) is dead and full of security
> issues.
>
> As an alternative, I found https://github.com/jonabbey/panda-imap,
> which is maintained, open to PRs, etc.
>

panda-imap is in C and is looks pretty well developed, with support for
several optional IMAP features. Since its well maintained, if they're up
for being included in PHP, that could be the way to go.


Regards
-Matt

---

## #73035 — Marco Pivetta — 2014-03-09T22:43:58+00:00

URL: https://externals.io/message/73003#73035 · In reply to: #73034

> Unfortunately for inclusion in core, its not c.
>

Is that really a negative note? As long as there is a *secure* solution, a
PHP implementation should be preferable.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #73041 — Ralf Lang — 2014-03-10T08:31:35+00:00

URL: https://externals.io/message/73003#73041 · In reply to: #73035

> 
> 
> > […]
> 
> Is that really a negative note? As long as there is a *secure* solution, a
> PHP implementation should be preferable.
> 
> Marco Pivetta

There are a number of high performance feature rich php-only imap
implementations, horde_imap being one of them.

I see no need for a c client. But do as you like if you have time to
maintain it.


-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

---

## #73042 — Pierre Joye — 2014-03-10T08:37:23+00:00

URL: https://externals.io/message/73003#73042 · In reply to: #73041

> 
> > […]
>
> There are a number of high performance feature rich php-only imap
> implementations, horde_imap being one of them.
>
> I see no need for a c client. But do as you like if you have time to
> maintain it.

I am not in favor in keeping ext/imap. I already stated it a couple of
times already on this list and already asked to remove it from core.

However there were objections and that's why I propose to rely on a
maintained c-client instead of the dead UW's c-client, which has so
many security issues as a bonus.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #73054 — Stas Malyshev — 2014-03-10T21:47:54+00:00

URL: https://externals.io/message/73003#73054 · In reply to: #73042

Hi!

> However there were objections and that's why I propose to rely on a
> maintained c-client instead of the dead UW's c-client, which has so
> many security issues as a bonus.

Looks like panda-imap is a fork of c-client, so I imagine it should not
be too hard to compile existing code with it, right?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227