G
Garu
This is not the system in question and sorry about the time and date....
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
V
VanguardLH
Garu said:Hi,
Has anyone encountered this strange problem (intermittent) in Outlook. We
sometimes get below error when sending email:
"The following recipient(s) cannot be reached: The recipient has been
deleted or has no e-mail address."
The recipient's email addresses in question are confirmed correct and
existing. We even get the same error when sending to users on the same
domain.
Please help.
Garu
You need to tell the recipient (via phone, chat, or some other means than
e-mail) to contact their e-mail provider. That error is issued by the
recipient's receiving mail server. You can't do anything about what the
mail server believes is or is not a valid e-mail account defined to that
mail server.
L
LD55ZRA
In your case the problem is your system because not only the time
is wrong but even your date is completely wrong. Perhaps you
should learn to keep and eye on it before worrying about bounced
emails.
In many cases correcting the date and time resolves most problems.
hth
--
THE INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY
KIND. LD55ZRA DISCLAIMS ALL WARRANTIES, EITHER EXPRESSED OR
IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL LD55ZRA
OR ITS ASSOCIATES BE LIABLE FOR ANY DAMAGES WHATSOEVER
INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF
BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF LD55ZRA OR ITS
ASSOCIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR
LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL
DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.
Copyright LD55ZRA 2010.
is wrong but even your date is completely wrong. Perhaps you
should learn to keep and eye on it before worrying about bounced
emails.
In many cases correcting the date and time resolves most problems.
hth
Thanks VanguardLH for that quick response. That was my first thought too
but the problem occurs on different recipients with different domain, email
provider & mail server.
--
THE INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY
KIND. LD55ZRA DISCLAIMS ALL WARRANTIES, EITHER EXPRESSED OR
IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL LD55ZRA
OR ITS ASSOCIATES BE LIABLE FOR ANY DAMAGES WHATSOEVER
INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF
BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF LD55ZRA OR ITS
ASSOCIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR
LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL
DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.
Copyright LD55ZRA 2010.
G
Garu
Hi,
Has anyone encountered this strange problem (intermittent) in Outlook. We
sometimes get below error when sending email:
"The following recipient(s) cannot be reached: The recipient has been
deleted or has no e-mail address."
The recipient's email addresses in question are confirmed correct and
existing. We even get the same error when sending to users on the same
domain.
Please help.
Garu
Has anyone encountered this strange problem (intermittent) in Outlook. We
sometimes get below error when sending email:
"The following recipient(s) cannot be reached: The recipient has been
deleted or has no e-mail address."
The recipient's email addresses in question are confirmed correct and
existing. We even get the same error when sending to users on the same
domain.
Please help.
Garu
V
VanguardLH
WHO is sending you an e-mail that contains "The following recipient(s)
cannot be reached"?
Do the Received headers show it is the recipient's receiving mail server
sending you back that e-mail? If so, that means the receiving mail server
actually accepted the e-mail BEFORE determining if the message was
deliverable (sometimes encountered when the recipient uses a forwarding
service since it has to accept and then forward before it knows if the
forwarding address is valid). Some misconfigured receiving mail servers
will also accept e-mails before they determine if the messages are
deliverable on their own domain. The only proper time to reject an e-mail
is DURING the mail session between the sending and receiving mail server.
The receiving mail server does its check, then issues an error status during
that mail session, and the sending mail server then sends back the e-mail
that it created to notify the sender.
If the Received headers show that the e-mail originated from your own mail
server then it could be your e-mail provider's mail server is screwed up.
However, it is still possible that you are passing invalid e-mail addresses
in the RCPT-TO commands that your e-mail client(s) gives to your sending
mail server. The sender's mail server won't know if the e-mail addresses
are valid until it has already accepted the client's e-mail data and then
later tries to actually connect to another mail server to send that e-mail
data.
In the NDR (non-delivery report) e-mail that you get back that says "The
following recipient(s) cannot be reached", is the rejected e-mail address
actually specified? If so, is it enclosed within quotes so you can tell
just exactly what is contained in the string that was used in the RCPT-TO
command that your sending mail server got from your clients? I've seen
where users added a trailing space at the end of an e-mail address, or have
included characters that are illegal in e-mail addresses (or simply not
allowed in the receiving domains since some mail servers will accept longer
strings or characters that another mail server won't allow). For example, I
might have a valid account with (e-mail address removed)
(I just made up that aliasing account so don't bother to send anything since
I won't receive it) but the sending mail server doesn't support a 3-segment
username or allow up to 20 characters per segment or not handle that long a
username. The receiving mail server can handle that long, multi-segmented
username but not the sending mail server. Not all mail servers have the
same abilities to handle the same structure for usernames in e-mail
addresses. Some will allow multiple underscores and others allow only one.
You would think that on sending the mail server doing the sending wouldn't
care but there are always limits in code and what the programmer considered
as plausible, feasible, or valid.
You also need to disable any superfluous e-mail scanning of outbound e-mails
by your anti-virus software. That could be interferring with the mail
session between your client and mail server. In fact, some AV programs
pretend they are the mail server and accept all of the message. Then they
interrogate the message and then pretend to be the client and connect to the
real mail server. I believe this is McAfee works. If there are problems
but not in your e-mail client, you have to go look at the AV program's logs
to see how it did its mail session with the mail server.
cannot be reached"?
Do the Received headers show it is the recipient's receiving mail server
sending you back that e-mail? If so, that means the receiving mail server
actually accepted the e-mail BEFORE determining if the message was
deliverable (sometimes encountered when the recipient uses a forwarding
service since it has to accept and then forward before it knows if the
forwarding address is valid). Some misconfigured receiving mail servers
will also accept e-mails before they determine if the messages are
deliverable on their own domain. The only proper time to reject an e-mail
is DURING the mail session between the sending and receiving mail server.
The receiving mail server does its check, then issues an error status during
that mail session, and the sending mail server then sends back the e-mail
that it created to notify the sender.
If the Received headers show that the e-mail originated from your own mail
server then it could be your e-mail provider's mail server is screwed up.
However, it is still possible that you are passing invalid e-mail addresses
in the RCPT-TO commands that your e-mail client(s) gives to your sending
mail server. The sender's mail server won't know if the e-mail addresses
are valid until it has already accepted the client's e-mail data and then
later tries to actually connect to another mail server to send that e-mail
data.
In the NDR (non-delivery report) e-mail that you get back that says "The
following recipient(s) cannot be reached", is the rejected e-mail address
actually specified? If so, is it enclosed within quotes so you can tell
just exactly what is contained in the string that was used in the RCPT-TO
command that your sending mail server got from your clients? I've seen
where users added a trailing space at the end of an e-mail address, or have
included characters that are illegal in e-mail addresses (or simply not
allowed in the receiving domains since some mail servers will accept longer
strings or characters that another mail server won't allow). For example, I
might have a valid account with (e-mail address removed)
(I just made up that aliasing account so don't bother to send anything since
I won't receive it) but the sending mail server doesn't support a 3-segment
username or allow up to 20 characters per segment or not handle that long a
username. The receiving mail server can handle that long, multi-segmented
username but not the sending mail server. Not all mail servers have the
same abilities to handle the same structure for usernames in e-mail
addresses. Some will allow multiple underscores and others allow only one.
You would think that on sending the mail server doing the sending wouldn't
care but there are always limits in code and what the programmer considered
as plausible, feasible, or valid.
You also need to disable any superfluous e-mail scanning of outbound e-mails
by your anti-virus software. That could be interferring with the mail
session between your client and mail server. In fact, some AV programs
pretend they are the mail server and accept all of the message. Then they
interrogate the message and then pretend to be the client and connect to the
real mail server. I believe this is McAfee works. If there are problems
but not in your e-mail client, you have to go look at the AV program's logs
to see how it did its mail session with the mail server.
G
Garu
The header doesn't show any details of the receiving mail server. The
undeliverable message is coming from "System Administrator" as seen in the
"From" field. We have confirmed that all of the unreachable receipient's
email addresses are typed correctly.
Below is an example of the undeliverable message:
---------------------------
"Your message did not reach some or all of the intended receipients.
Subject: <the actual subject is mentioned here>
Sent: <time and date mentioned here>
The following receipient(s) cannot be reached:
<email address of the recipient(s) with quotes'>
The recipient has been deleted or has no e-mail address."
-------------------------
Garu
The 'FROM'
undeliverable message is coming from "System Administrator" as seen in the
"From" field. We have confirmed that all of the unreachable receipient's
email addresses are typed correctly.
Below is an example of the undeliverable message:
---------------------------
"Your message did not reach some or all of the intended receipients.
Subject: <the actual subject is mentioned here>
Sent: <time and date mentioned here>
The following receipient(s) cannot be reached:
<email address of the recipient(s) with quotes'>
The recipient has been deleted or has no e-mail address."
-------------------------
Garu
The 'FROM'
V
VanguardLH
Garu said:The header doesn't show any details of the receiving mail server. The
undeliverable message is coming from "System Administrator" as seen in the
"From" field.
So the Received headers show only your own sending mail server?
We have confirmed that all of the unreachable receipient's
email addresses are typed correctly.
Below is an example of the undeliverable message:
---------------------------
"Your message did not reach some or all of the intended receipients.
Subject: <the actual subject is mentioned here>
Sent: <time and date mentioned here>
The following receipient(s) cannot be reached:
<email address of the recipient(s) with quotes'>
The recipient has been deleted or has no e-mail address."
-------------------------
During the mail session between your sending mail server and the recipient's
mail server, the sending mail server issued the RCPT-TO command to the
receiving mail server. The receiving mail server came back with an error
status saying there is no such user there.
Since the receiving mail server rejected the message during the mail session
between it and the sending mail server, it must be the sending mail server
that sent you the NDR (non-delivery report) e-mail. Possibly the e-mail
address your sending mail server is wrong that it specifies to the receiving
mail server. You could look at its logs to see just what it specified in
the RCPT-TO command(s).
You might be specifying the correct e-mail address in your e-mail client
that it gives during its RCPT-TO command to your sending mail server;
however, what the receiving mail server sees from your sending mail server
it doesn't like.
If it isn't the e-mail address in the RCPT-TO command that is wrong from
your sending mail server then something between your e-mail client and your
sending mail server is corrupting the e-mail addresses. That could be an
add-on that you installed into Outlook, so try loading Outlook in its safe
mode ("outlook.exe /safe") which doesn't load any enabled add-ons that you
installed into Outlook. Did you yet get around to disabling the superfluous
e-mail scanning in your anti-virus program?
B
Brian Tillman [MVP-Outlook]
During the mail session between your sending mail server and the recipient's
mail server, the sending mail server issued the RCPT-TO command to the
receiving mail server. The receiving mail server came back with an error
status saying there is no such user there.
Since the receiving mail server rejected the message during the mail session
between it and the sending mail server, it must be the sending mail server
that sent you the NDR (non-delivery report) e-mail.
I agree with you. I'd open the Sent Items copy of the message, double-click
the receipient address and see what the "E-mail Properties" dialogue contains
in the "E-mail Address" field. I suspect that is incorrect.