"VanguardLH" wrote in message
When we try to send an email to this contact she does not receive it
but she has no problem sending to us.
No errors come up and it looks like it was sent.
What has the recipient tried so far (so we don't end up duplicating
suggestions to do the same actions that she already performed)? Looked
in the trash or spam folders? Disabled or deleted any server-side rules
or filters in her account? Sees e-mails from other senders okay but
just not you? Did she disable her anti-spam program or anything else
that interrogates her e-mails?
What have you as the sender tried so far (so we don't end up duplicating
suggestions to do the same actions you already performed)? Send from a
different domain? BCC'ed yourself (and at a *different* domain than
from where you send) to ensure your e-mail provider's SMTP server is
actually sending the e-mails (and not just simply accepting them from
you)? Did you try disabling your anti-spam, anti-virus, or any other
program that interrogates your outbound e-mails?
Some anti-virus programs act as a transparent proxy. They interrogate
your outbound e-mail traffic byte-by-byte as it passes through their
proxy. That's how they interrogate its content to make sure your
outbound e-mails aren't infected. However, some AV products pretend
they are your SMTP server. They don't operate as a proxy but instead as
a mail server. They accept your complete outbound e-mail which means
your client gets a good status back from the phony SMTP server (the one
used by the AV program). Then the AV program inspects the entire e-mail
message for malware. If it's okay then it pretends it is your e-mail
client and connects to your real SMTP server to finally transmit your
outbound e-mail. If there is an error between the AV program's bogus
SMTP server and the real SMTP server, your e-mail client won't ever know
that because it was NOT involved in the mail session with your real SMTP
server. Only the logs in your AV program might show there was an error
between its intercepting SMTP server and the real SMTP server. So you
won't see a problem in your e-mail client because the AV program's SMTP
server is always returning an OK status on every e-mail you send from
your client. You have to inspect the AV program (or anti-spam program
or whatever intercepts your outbound e-mails) to see if its logs report
a problem. You might then find there was an invalid domain or undefined
account (username) reported by the receiving SMTP server but only your
AV program's bogus SMTP server would know about that status.
You have a mail session between your client and the AV program's SMTP
server and it sends back an OK status. Your client is now out of the
picture an no longer involved. Your AV program's SMTP server after
interrogating your message then starts another mail session between it
and the real SMTP server. That 2nd mail session doesn't involve your
e-mail client. That's why AV, anti-spam, or other e-mail interrogating
software that operates as a proxy to immediately pass on the e-mail
traffic so your e-mail client gets status from the real SMTP server are
preferred. Of course, if your AV program was working well then you
never need to have it inspect your outbound e-mails. After all, if it
can find the pest on your host then how could it possible not already be
detected by the time you attach it to an e-mail?
Do you use the recipient's e-mails to define the reply-to e-mail address
or do you manually type it into your new outbound e-mails to her? She
might have the wrong e-mail address in her From or Reply-To headers so
you end up recording (in your contacts) and sending to the wrong e-mail
address on your end. Just because her e-mails get delivered to you
doesn't mean she specified the correct e-mail address for herself in
those e-mails you got from here. That you don't get an error
immediately simply means your SMTP server accepted your outbound e-mail.
It doesn't mandate the recipient's e-mail address is valid. Not until
your SMTP server actually sends the e-mail will it know if the domain is
valid and if there is an account with the specified user name at that
domain.
If the domain was invalid then your SMTP server would send back an NDR
(non-delivery report). Normally (in a good setup) the sending SMTP
server gets an immediate error from the receiving SMTP server if the
account doesn't exist at the destination. That is, *during* the mail
session between sending and receiving servers an error is sent by the
receiving server and the sending server immediately sends you back an
NDR (but *not* during your mail session with your SMTP server but later
during the mail session with the other SMTP server). So it's quite
possible that your SMTP server cannot send (invalid domain) or gets an
error (no such account there) and sends back an NDR but *you* are
filtering out those status e-mails. That means you need to check your
server- and client-side filtering to make sure you get the NDRs.
Some mail servers are [deliberately] misconfigured, especially those
that merely forward e-mails rather than used as a normal e-mail account.
When they are the receiving server and instead of immediately sending
back an ERR status when no such account is defined on their end, they
merely accept all e-mails. After the mail session is between the
sending and receiving mail servers, the receiving mail server then
decides later to process the received e-mail whereupon then the check is
made to determine if the recipient is defined there. When they find
there is no such user, the user's quota is exceeded (they used up their
disk space for their account), the size of the message exceeds the max
permitted for the recipient's account, or some other problem, they send
back an NDR to the sender. However, at that point, the receiving server
has no idea who was the real sender. All they have is what the sender
claimed was their e-mail address - and we all know that spammers don't
specify their real e-mail addresses. During the mail session, the
receiving mail server can send back status immediately to the sending
mail server without ever knowing the originating e-mail address. It
doesn't care. The sending server is supposed to know which account was
used at it to send the message and issues an NDR to its user's account.
But after the mail session is over, an NDR only has what the sender said
was their e-mail address and the NDR gets sent there. So maybe you are
specifying a From, Reply-To, or Return-Path header with an e-mail
address that doesn't point back to the account where you expect the NDRs
to get delivered, or your return e-mail address is invalid so the
receiving mail server tries to send the NDR to an invalid address which
fails but obviously it has nowhere else to try to send the NDR e-mail.
You need to look at what is in the headers of your outbound e-mails.
You also need to check that your real SMTP server is actually sending
your outbound e-mails. Sending e-mails to yourself (i.e., you send from
your e-mail provider to your own account at that same e-mail provider)
is not a valid test. Most e-mail services will short-circuit e-mails
sent from yourself to yourself. They simply redirect your message back
into your account without ever touching their SMTP server. In fact,
some providers will automatically filter out such e-mails since few
users send e-mails to themselves (e.g., Gmail filters out e-mails sent
by you to yourself at Gmail). You might have your own client- or
server-side filters that do the same. To ensure your SMTP server is
actually sending out your e-mails, send a test e-mail to the problematic
recipient while also including yourself as a BCC recipient but where the
target e-mail address for yourself is at some OTHER e-mail provider.
Saying you send e-mails using your Hotmail account. BCC yourself in the
test e-mail to your Gmail account. Then if you see your test e-mail
from Hotmail get delivered to your Gmail account then you can be sure
that your Hotmail SMTP server actually sent out your test e-mail, plus
you can inspect the headers (as they will be full headers rather than
some internal redirection from your account back into your account).
On our side we have tried to reply, forward and manually type in the email
address. Other people in our company send emails to her without a problem.
I have sent a test message from our email service's webmail and it also
fails.
We do not get any indication that the email has failed (no NDR) and the
outbox is empty.
She has had her ISP check into this and they say it is not on her end.
We use a pop/smtp server hosted by USA.net they have checked their filters
and found no problems on that side. I have our email accounts set up to send
via USA.net's
smtp not our ISP's. I did try to use our ISP's smtp server but the result is
the same.
But here is another interesting thing, He can reply to her from his phone
without a problem
the phone is setup the same as our internal email clients.
