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
f...@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 "f...@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 "f...@example..com" is
"Invalid e-mail address (f...@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
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,
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....@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....@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....@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?
imp mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: imp-unsubscr...@lists.horde.org