Fixed.

Please test this commit:

http://lists.horde.org/archives/cvs/Week-of-Mon-20080519/078884.html

I really don't want to release with this an issue, so I'm going to 
take a shot at it.

This commit:

http://cvs.horde.org/diff.php?r1=1.297&r2=1.298&f=imp%2Flib%2FCompose.php



... broke it. IMP_Compose::recipientList() doesn't understand groups, 
and now it tries to rewrite the headers, thus, groups get broken. The 
foreach loop around line 1155 needs to be changed to handle groupname 
being set on $ob.

oh, i see, if it's null, RFC822 uses the default class value, which is 
true. But we check for groupname, which is only set if $nest_groups is 
true.

I'm almost with you, but null _is_ a false value in PHP, and further, 
if you look at Mail/RFC822.php, $nest_groups is given a default value 
of null.

...to be more exact, the real problem appeared to be that in 
Compose.php method recipientList it is assumed that the 
IMP::parseAddressList($email) in line 1149 (or thereabouts) would 
return the recipient addresses in flat format (that is, it would 
return an array of objects which would each have the properties 
mailbox and host, as assumed in line 1155 and later on). However, my 
apache error_log ended up with error messages such as "PHP Notice:   
Undefined property:  stdClass::$mailbox in 
/var/www/html/horde/imp/lib/Compose.php on line 1155". This would mean 
that for each contact list, we'd end up with addresses with an empty 
mailbox part and the default domain as the host part. And the reason 
appeared to be that the IMP::parseAddressList would return contact 
list type addresses in the nested form, that is, the returned objects 
in the array would have properties such as groupname and addresses, 
the latter of which would contain an array of the kind of objects that 
the recipientList method was expecting. Looking at IMP.php line 435 in 
method parseAddressList, you can see that $parser->parseAddressList 
was called with null as the third argument. Now, the third argument 
should be a boolean telling whether we want the group (contact list) 
addresses in flat format or in the nested format. And null is not a 
false value in php. When I changed that null to false (as in the patch 
I submitted previously), parser->parseAddressList started giving 
contact list parses in the flat format, and everything started to work.

Both. But I've mostly tried with just one distribution list, which 
doesn't result in a comma anywhere, and it was broken the way I 
mentioned (before I changed the one line I mentioned in IMP.php). (Now 
that I've changed that line, everything works, whether there is a 
comma after the semicolon or not - and it should work, too, because 
that'd mean that there is only an empty address between the 
distribution list and the next address.)

That doesn't look correct, because a comma shouldn't be added after 
the semicolon in the first place. How do you add the distributions 
lists, with auto-completion or with the address book popup?

I'm pretty confident that we already fixed this at least in one place 
in the past.

...OK, the RFC822::parseAddressList() method works as before, but it 
was called with a null nest_groups argument when it should've been 
false (in IMP::parseAddressList). Patch attached; everything seems to 
work, at least for me. Sorry for spamming you...

...wrong guess... apparently, either IMP::parseAddressList or 
Compose::recipientList should be able to handle two types of return 
array objects, namely, plain address objects (which have members 
"mailbox" and "host") AND group objects (which have a member 
"addresses" which seem to have the "mailbox" and "host" members)...

Some more info... apparently, the Horde/pear/Mail/RFC822.php / 
parseAddressList method works slightly differently from what it used 
to, say, in Horde 3.1.5, at least it seems that it doesn't succeed in 
parsing the "list: mm@a.tld, nn@b.tld;" type address entries any more 
(with the same options, that is, $nest_groups,$validate,$limit all 
false).

If I create a contact list in Turba and add the list as the recipient 
in IMP compose window, what ends up in the To: header is something 
like "listname: address1@foo.tld, address2@bar.tld, address3@baz.tld;" 
- if I add another list from address book, it goes to the end of the 
previous one, separated by a comma (so there'll be a semicolon and a 
comma in the middle). If I try to send the message, it fails - SMTP 
server complains about missing RCPT (5.0.0). I looked for the bug in 
Compose.php - apparently, the recipientList function receives the 
string as-is in $hdr['to'], and the  $arr = 
array_filter(array_map('trim', MIME::rfc822Explode($hdr[$key], ','))); 
ends up having as array items the "listname: address1@foo.tld, 
address2@bar.tld, address3@baz.tld;" parts (first item would be 
"listname: address1@foo.tld, address2@bar.tld, address3@baz.tld;"

and second item would be "listname2: address4@foo.tld, 
address5@bar.tld, address6@baz.tld;" if the original to header 
would've been "listname: address1@foo.tld, address2@bar.tld, 
address3@baz.tld;, "listname2: address4@foo.tld, address5@bar.tld, 
address6@baz.tld;". These items then get fed to 
IMP::parseAddressList(), which results in an object with the empty 
string in $ob->mailbox and the default sender domain in $ob->host... 
So each contact list ends up as "@<default domain>". I wonder which 
part in the control chain should parse the "listname: 
address1@foo.tld, address2@bar.tld, address3@baz.tld;" parts..