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 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, i.e. trying to send an email to "" from 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 when trying to send an email to "" is "Invalid e-mail address (" 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 <> 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. "" 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. "", 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. "" and one tries to send an email to the misspelled "" address again, then inside the hook the $addr->mailbox variable will be set to "john.doe", but the $addr->host variable will be "" (as given in the "maildomain" setting) and not "" (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 "" suffix applied. (In the imp_sentmail table, this will be recorded as ""). 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?

imp mailing list
Frequently Asked Questions:
To unsubscribe, mail:

Reply via email to