We have an issue with a CPANEL installation and HORDE is the webmail 
client one of our customers has chosen. We have hundreds of customers 
and thousands of domains and many of them are using HORDE as their 
webmail portal.

Just Friday one of our customers reported that they are getting this 
"Address is missing domain" when sending email on only one of their 
domains.  None of the others and no other customer is reporting it and 
we cannot reproduce on any of our domains.

We logged into the customer account with their permission and were 
able to reproduce the issue without fail. They cannot send email from 
this domain with HORDE no matter what.

We are not using LDAP or any non-standard CPANEL configuration.  We 
have not even done a "branding" of CPANEL.

Please advise, we will otherwise have to direct the customer to use a 
different webmail client.

Not sure if related, but I hit an indentical issue.

Turns out the cause of at my end was because the preferences system 
was set to PHP sessions. Any attempt I made to store an indentity was 
not being saved (the Identity form showed it had saved, but on closing 
& returning to the page it was not saved onbviously) -- which lead to 
any sent mail failing with the above error.

The moment I updated it to use  SQL storage and set it all right, it worked.

I'm actually facing a similar problem to the one stated here. Default 
identity didn't had a default address ( and wasn't required to until 
last update apparently ) but now I can't add any because the server 
fail authentication. According to the log it fail authentication 
because of a password issue. I searched where to enter the password 
during the identity edit and I can't find somewhere. Though the 
password IS good because I'm actually authenticated against this same 
server to connect to horde.

It seems to, yes. It shows up as being delivered from the full email 
address, and my name shows the full thing when clicked in Horde.

Does your *From* address have a domain (i.e. your Identity)?  That's 
the only way I can reproduce this.

Also, in reply to your comment that it looks like the first two 
examples aren't being triggered: yes, they are. I don't know exactly 
why they look the way they do, but throwing exceptions for a flat 
string or a different variable worked and displayed the right value. 
Additionally, those particular popups would not appear unless the 
exception was there.

I don't know the structure of your variables, so I can't really 
comment on these traces. They were done at line 412, for $ob and 
$this. Had to concatenate the files, so I divided them with some 
headers.

Your first two examples don't prove anything.  It looks like they 
aren't even triggered since the error message displayed in the UI does 
not match up with the text/type of Exception thrown.

Instead of using exceptions, it is much easier to use Horde::debug().   
(see below).  You should dump the contents of both $ob and $this.

My guess is that $this->_rfc822ParseDomain() is called and $host is 
empty, so the strlen($host) fails and $ob->host is never set (why it 
is null).



Horde::debug() documentation: http://wiki.horde.org/Doc/Dev/DebugH4

Alright, I added and modified exception throwing to do some tests, 
using 'mail@gmail.com'. I've attached a four-part image of screencaps 
of the file and the results.

The results were that at line 401, $host is 'mail@gmail.com', (screen 
1) and $ob->host is set to that. (screen 2)  At that time, it is 
correct. However, at line 414, $ob->host has become null. (screen 3) 
Literally nothing happens to it in between those points, because even 
if an exception is thrown it doesn't do anything to the data. 
$this->_params['default_domain'] is also null, which means that it 
doesn't overwrite $ob->host. (screen 4)

The string "Address is missing domain" does not occur anywhere else in 
the file, nor in any other file, so this must be the place where 
something mysterious happens to $ob->host.

I don't really know the structure of the $ob variable, so I'm not sure 
what else to check or why the mail delivery succeeds when I remove the 
exception. What else can I do to help collect evidence?

We have multiple unit tests that check for this, and none fail.  So 
you will have to provide a failing unit test that proves otherwise.

As mentioned, commenting out the code doesn't have anything to do with 
whether the code is correct.  If the verification code is passed an 
email address without a domain, that's a problem with IMP's 
configuration - commenting out the exception doesn't change anything.

In short, you should add a debug/print statement where the exception 
is thrown to determine what the value is at that point.

Oh, no, I totally understand that, which is why I'm so baffled about 
it. I read the code myself a few times over and it seems to make 
perfect sense, but I definitely have a default domain configured. I 
even set and unset that parameter multiple times, and tried sending to 
different domains including my own, it still threw the error.

Commenting the exception throw lets the mail go through and delivery 
is successful, which seems to leave the only possibility being 
something wrong with the code, unless there is some other factor at 
work here that I'm not aware of. But overall it seems pretty simple. 
If the address you're sending to doesn't have a domain, it uses your 
default. If you don't have a default, it throws an error.

If that's the line that's throwing an error, then you almost certainly 
do not have a default domain defined.

There's absolutely nothing wrong with the validation code - if it 
reaches that point, the e-mail address lacks a domain.  You can't send 
mail without a domain so it absolutely has to throw an error in that 
instance.

My server setup is Postfix+Dovecot, authenticating against AD as LDAP. 
For some reason, Imp complains, no matter the address, that the domain 
part is missing. My default domain is filled in as 
'cipherprosolutions.com', but it also complains when it's blank or set 
to localhost.

Commenting out line 414 in /usr/share/php/Horde/Mail/Rfc822.php works 
as a temporary fix, and mail successfully reaches its destination (in 
my tests, Gmail), so it seems like the problem is in the address 
validation.