[imp] Trouble with email addresses containing empty domain labels

[Jens Wahnes]

Jens Wahnes wrote:
> Jens Wahnes wrote:
>> Jan Schneider wrote:
>>
>>> I was able to track this down to Horde_Idna. The error will be catched
>>> in Horde_Idna 1.1.0 and displayed smarter in IMP 6.2.18.
>>
>> I looked into this again today. Even though I have got the new versions
>> installed (both Horde_Idna 1.1.0 and IMP 6.2.18), I still seem to get
>> the same error, i.e. no warning when sending an email to an address like
>> foo at example..com and the mail is actually being sent to "foo" without
>> any domain. Are there any other dependencies that I may have missed?
> 
> I can see this working on demo.horde.org, i.e. trying to send an email 
> to "foo at example..com" from demo.horde.org is aborted with an error 
> message.  Still, this does not happen in our setup.  On our systems, the 
> email is being sent to the "localpart only" address instead.  Is nobody 
> else having this problem?
> 
> Looking for things that are unique to our setup, I thought that this 
> might be because we use a "pre_sent" hook to add headers to outgoing 
> email messages, but even when disabling that hook, the problem persists. 
>   I don't seem to be getting any hint from the log files neither.  So 
> I'm running out of clues what part of our configuration might be causing 
> the trouble.  Maybe someone has got an idea how to debug this further? 
> Could it be caused by other hooks we've got?
> 
> What strikes me though is the fact the error message I get on 
> demo.horde.org when trying to send an email to "foo at example..com" is 
> "Invalid e-mail address (foo at example..com)."
> According to the code that I see in .../imp/lib/Compose.php around line 
> 1300, this would be the error message that is generated upon a 
> Horde_Mail_Exception, not upon Horde_Idna_Exception, because in the 
> latter case, the message would contain a colon.  I thought this whole 
> problem was related to Horde_Idna?  To me, the code added in the commit 
> <https://github.com/horde/horde/commit/36b0073ab1184a4b6f2a2beea3c286ce087c763d> 
> suggests that catching Horde_Idna_Exception is supposed to fix the 
> problem?  Or am I on the wrong track completely?


I was revisiting this problem today as it persists in our environment, 
using

Horde_Idna                   1.1.1   stable
imp                          6.2.21  stable

What I was able to find out is that whether or not the problem will be 
caught by the fix mentioned above depends on the "maildomain" setting 
for the mail server used (as set in Imp's backends.local.php).  If 
"maildomain" is set to the empty string, as is the case in the 
"advanced" configuration given as an example in backends.php, an error 
message is displayed if one tries to send an email to e.g. 
"john.doe at example..org" with two adjacent dots in the domain name. 
However, if the "maildomain" property of the mail server is set to a 
proper hostname, e.g. "example.net", no warning is displayed and the 
email is sent to e.g. "john.joe" without a domain name.

I tried to work around this using a hook, that is "public function 
compose_addr(Horde_Mail_Rfc822_Address $addr)" as described in Imp's 
hooks.php.dist.  The idea was to look for addresses that contain ".." in 
the host part of the email address and reject them in the hook. 
However, that did not work either.  When the backend's "maildomain" 
property is set to e.g. "example.net" and one tries to send an email to 
the misspelled "john.doe at example..org" address again, then inside the 
hook the $addr->mailbox variable will be set to "john.doe", but the 
$addr->host variable will be "example.net" (as given in the "maildomain" 
setting) and not "example..org" (as given by the user writing the email 
message).  So one cannot catch the wrong email address there.  Of 
course, the email is sent to just "john.doe" (without domain name) 
eventually without the "example.net" suffix applied.  (In the 
imp_sentmail table, this will be recorded as "john.doe at example..org"). 
If anyone else is going to try this out, please note that changes made 
to backends.local.php will only be applied to new sessions, so one has 
to re-login to properly test those changes.

Any chance for an easy fix to this?


Thanks
Jens