Another solution, at least with IMP 6.2, is to send using an LMTP 
server (instead of SMTP).  Since LMTP is specifically defined to 
reject messages at send-time if they can't be delivered (as opposed to 
SMTP, which is designed to ALWAYS accept messages even if the e-mails 
are currently unreachable, etc.).

550 errors have nothing to do with "typos".  That *may* be a cause, 
but it certainly isn't the only cause.  And it almost certainly isn't 
the most common cause since the vast majority of SMTP servers do NOT 
do mailbox verification during negotiation.
Again, 550 errors have nothing to do with typos.  It may trigger one, 
but 550 != invalid e-mail address.
I believe your issue is that you are expecting/wanting SMTP to do 
email validation.  Most people don't want this ... since it is 
entirely site dependent.
Again... you are assuming this is an issue with e-mail addresses 
format and/or existence.  But most 550 errors have nothing to do with 
this.

A far more common issue would be a DNS glitch.  i.e. you send to 
foo@example.com, but for some reason example.com is not resolvable at 
the minute.  By definition, this is a permanent error (example.com 
doesn't exist) so this would be a 550.

So you obviously can't tell a user that their e-mail can't be sent 
because foo@example.com is invalid or is mistyped because that is 
simply an incorrect statement.  And since there is no way of knowing 
why the message transmission failed, you can't be any more specific 
than that.

Which is why almost every SMTP server doesn't try to validate at the 
submission stage anymore, since transient errors like the DNS issue 
can be fixed without further user intervention (or the user even 
knowing something was wrong).

If you want to be doing e-mail validation (for, say, local addresses), 
there is an IMP hook for precisely these kind of purposes: 
'compose_addr'.

True, but this misses the point that in the text of the 550 error is 
the specific address that caused the error.

The recent commit changing the message text still doesn't help in 
identifying the faulty address. It ends up intentionally hiding 
information from the end-user; information they need in order to fix 
their typo.

It's not a problem with only one destination address, but when a user 
types an adhoc To/CC list including 10+ local users, typos do happen.   
   WIth remote addresses, these just bounce later (with non-translated 
errors); but with local addresses, the message does not send until the 
error is corrected.

Not telling the user WHICH address is the problem is a bad idea, and 
that's just what hiding this message does.
I understand the desire to translate everything in the UI, but the 
translation of "Mailbox unavailable", without any details, will help 
nobody; while "<test@example.com>...  User unknown" (even 
untranslated) will at least tell the user WHERE the issue is.
Might I suggest, instead of the original "Mailbox unavailable", or the 
new "Message could not be delivered - the address was not found, is 
unknown, or is not receiving messages.", to append the original error 
text to the end of "Mailbox unavailable"?

That way, there is a translated error AND the necessary details to fix 
the problem.

Resulting in errors reading like this (with the first two lines 
localized by Horde, and the last one dependent on the SMTP server):

There was an error sending your message:
Mailbox unavailable:
<test@example.com>... User unknown

Horde_Smtp 1.4.1

Changes have been made in Git (master):

commit 1464d793ebd5c92c894b7dd5b07d10de762dedb9
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Tue Mar 4 12:25:22 2014 -0700

     [mms] Better exception message for a 550 error, since it is 
common and may be displayed to an end user (Request #12990).

  framework/Smtp/lib/Horde/Smtp/Exception.php |    7 ++++++-
  framework/Smtp/package.xml                  |    4 ++--
  2 files changed, 8 insertions(+), 3 deletions(-)

http://git.horde.org/horde-git/-/commit/1464d793ebd5c92c894b7dd5b07d10de762dedb9

From RFC 5321 [4.2.2], that is the meaning of a 550 code:

    550  Requested action not taken: mailbox unavailable (e.g., mailbox
       not found, no access, or command rejected for policy reasons)

And we shouldn't be showing the response text from the SMTP server to 
the users if at all possible, since for non-english speakers it's not 
going to make any sense.

I wouldn't be opposed to making the error message clearer - or at 
least distinguish it more from a 450 code.

When sending to addresses that the local SMTP server will reject 
(invalid accounts at local domains, for instance), the error code and 
message (such as "There was an error sending your message: 
<testxyz@example.com>... User Unknown") is not displayed in the IMP 
Compose window.

Instead, IMP just displays "There was an error sending your message: 
Mailbox unavailable. "

This is occuring when "550 5.1.1 <xyztest@example.com>... User 
unknown" is returned from the SMTP server for invalid local users.

Removing the case statement for error 550 in 
lib/Horde/Smtp/Exception.php (as in the attached patch) does stop it 
from stomping on the detailed message with "Mailbox unavailable", and 
returns the correct detailed error message, but I'm not sure if that 
is the correct fix.

horde                     5.1.5
imp                       6.1.6
Horde_Core                2.11.1
Horde_Smtp                1.4.0