[#13608] "Address is missing domain" when sending mail
Summary "Address is missing domain" when sending mail
Queue IMP
Queue Version 6.2.2
Type Bug
State Assigned
Priority 1. Low
Owners Horde Developers
Requester tprobinson@cipherprosolutions.com
Created 2014-09-29 (1876 days ago)
Due
Updated 2016-11-20 (1093 days ago)
Assigned 2016-01-25 (1393 days ago)
Resolved
Milestone
Patch No

Comments
tprobinson@cipherprosolutions.com 2014-09-29 05:53:16
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.

Michael Slusarz <slusarz@horde.org> 2014-09-30 00:36:35
> 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.

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.

tprobinson@cipherprosolutions.com 2014-09-30 02:37:39
> 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.

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.

Michael Slusarz <slusarz@horde.org> 2014-10-02 03:14:51
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.

tprobinson@cipherprosolutions.com 2014-10-02 05:28:40
> 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.

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?

Michael Slusarz <slusarz@horde.org> 2014-10-17 17:34:51
> The results were that at line 401, $host is 'mail@gmail.com', 
> (screen 1) and $ob->host is set to that. (screen 2)

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

tprobinson@cipherprosolutions.com 2014-10-23 18:02:19
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.

tprobinson@cipherprosolutions.com 2014-10-23 18:06:25
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.

Michael Slusarz <slusarz@horde.org> 2014-11-03 02:12:56
Does your *From* address have a domain (i.e. your Identity)?  That's 
the only way I can reproduce this.

tprobinson@cipherprosolutions.com 2014-11-10 08:32:38
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.

bonnaud@hotmail.com 2015-06-05 02:49:54
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.


erle@erlepereira.com 2016-11-20 04:21:45
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.