[imp] "To:" and "Cc:" addresses in IMP 3.1

[Ari Heikkinen]

Hi,

On Mon, 16 Dec 2002, Michael M Slusarz wrote:

> Quoting Ari Heikkinen <aheikin@dlr.pspt.fi>:
>
> | On Wed, 11 Dec 2002, Michael M Slusarz wrote:
> |
> | > Quoting Ari Heikkinen <aheikin@dlr.pspt.fi>:
> | >
> | > | Hi,
> | > |
> | > | I've just installed IMP 3.1 and it works fine otherwise but seems to
> | > | generate e-mail addresses for "To:" and "Cc:" fields differently than
> | > | IMP 2.2.8 when composing new messages.
> | > |
> | > | Say I'm composing a new message and put a@b into "To:" field. IMP 3.1
> | > | appears to convert the "To:" field to look like this in the header:
> | > |
> | > | To: "" <a@b>
> | > |
> | > | ...whereas on IMP 2.2.8 it would look like this:
> | > |
> | > | To: a@b
> | > |
> | > | Is there any way to configure IMP 3.1 for the latter behavior
> | (without
> | > | that annoying address conversion) ?
> | >
> | > I still can't reproduce this.  Make sure none of the hooks are set in
> | > conf.php.
> |
> | Checked conf.php and none of the hooks seem to be set.. What would be the
> | best place to look at in horde/imp source to determine what would cause
> | this address conversion?
> |
> | (that is, is there any central function in horde/imp that's used for
> | fixing email addresses throughout the system?)
>
> Just the functions in IMP.php and MIME.php - that's where I looked.  But I
> _still_ can't reproduce this.  Someone else will have to step up and show
> me where/why/how this is happening.

Already solved it last week..

It was caused by a bug (or a feature?) in the c-client version (imap-2002)
I compiled PHP with.

I traced this down to PHP's function named imap_rfc822_write_address() and
after checking PHP's source noticed it calls c-client's function named
rfc822_write_address_full() (located in "src/c-client/rfc822.c" in the
imap sources) which didn't check if the personal info was an empty string.

Noticed a newer imap was available at ftp://ftp.cac.washington.edu/imap/
and compiling PHP with it (imap-2002a.DEV.SNAP-0212051126) fixed the
problem (as this version does the proper checks).

> michael

Ari Heikkinen - PSPT <e-mail: aheikin@dlr.pspt.fi>