Jasper said:
We are having a problem with 1 email address not getting the email.
I sent a test message to the contact and CC it to my email, I received it
but the contact did not.
All other contacts work fine and the email is correct.
The email will go to the sent items folder. The outbox is empty.
The contact says that she had her end tested and it is not at her end.
That test is invalid. For many ISPs or e-mail providers, if you use
your account to send yourself a test e-mail, it never goes out their
outbound boundary SMTP mail server. Instead it gets immediately
rerouted internally right back into your account. Your test e-mail went
out from your account, never went to their SMTP server, and just got
rerouted right back into your account. That is, your test e-mail from
yourself sent using your account never actually got e-mailed using their
server but just got dumped back into your account. They don't need to
waste their server's valuable and limited resources to route an e-mail
that never goes out from their network.
For a valid test to see that your e-mail provider actually sent your
e-mails, you need to have your test e-mail or a copy of your e-mails
sent to a DIFFERENT e-mail provider. Say you're sending e-mails using
your ISP's SMTP server. That means you need to send a test e-mail or CC
yourself to an e-mail account that you have elsewhere, like to a Gmail
or Hotmail account that you have. Make sure you are sending your test
or copied e-mails used to validate your SMTP server operation by sending
OUTSIDE your SMTP server's domain. If you want to test your e-mails are
getting out then send them somewhere outside your sending e-mail
service.
That others (outside your e-mail domain) are getting your e-mails
(assuming you verified that since you didn't mention it) means your
e-mails are getting sent to other [receiving] SMTP server outside your
[sending] SMTP server.
The Outbox folder will only be non-empty DURING an e-mail session. Your
e-mail client will move the draft of your e-mail into the Outbox folder
WHEN it connects to the SMTP mail server and establishes a mail session
with that server. Items in the Outbox are currently being sent. If
they remain there after the mail session is over or when no mail session
is currently being established then something failed in the e-mail
client. When you compose a message and then send it, it gets moved into
the Outbox and your e-mail client connects to actually send it to the
server. If you compose a message but don't send, it gets saved in the
Drafts folder. When you tell your e-mail client to send pending
e-mails, the item moves from the Drafts folder into the Outbox folder
and the e-mail client connects to the server to send it. If the item
remains in the Outbox folder, it did NOT get sent.
You can't do anything regarding filters (server- or client-side) at the
recipient's end. Their e-mail provider may be using a blacklist. Since
you are sending to multiple recipients and do that often, you may be
getting reported as a spam source which results in a public DNS
blacklist getting update which the recipient's e-mail provider may be
using. That means they reject the spam upon delivery and it never even
reaches the recipient's mailbox. Usually, however, the rejection
results in the sender getting a DSN (delivery status notification) that
tells them their e-mail was undeliverable or rejected. However, many
e-mail servers are misconfigured (sometimes deliberately) to accept all
e-mails and then check later if they are deliverable or to be rejected.
That means the DSN has to be sent to the return headers (From, Reply-To,
Return-Path) in the e-mails since that's the only info available in that
e-mail. Alas, those headers are inserted by the client that composed
the e-mail and spammers don't specify their own true e-mail address.
They may, however, specify someone else's valid e-mail address which
results in that innocent getting slammed with tons of DSNs for e-mails
they never sent. Best is to have the receiving mail server reject an
e-mail DURING its mail session with the sending mail server since only
then does it know for sure who to notify, and then it's up to the
sending mail server to figure out where to send the DSN (which is the
account used to send the e-mail through that sending mail server). So
you could be running afoul of a blacklist at the recipient's e-mail
service. Since the recipient will never get those e-mails in their
mailbox, they can't report ham reported as spam to their e-mail
provider. It's unlikely that an e-mail provider will do anything to
update its blacklist from requests from non-customers. You would have
to tell your recipient to contact their e-mail provider to get your
removed from that e-mail provider's blacklist. They don't want to know
who you are but whose e-mail service you use to send your e-mails.
Besides a blacklist, e-mail providers usually have server-side spam
filtering. In that case, usually the spam still gets delivered to the
recipient's e-mail account but put into the Spam or Junk folder. If the
recipient is using POP to access their e-mail account, they won't see
any e-mails in the Junk/Spam/Trash folders or any folder other than the
Inbox folder. If using IMAP, they will see e-mails in the folder to
which they've subscribed (you configure your local IMAP-capable e-mail
client to subscribe to folders in your e-mail account that provides IMAP
access, so if you don't subscribe to a folder then your IMAP client
won't see any e-mails in that server-side folder to retrieve and
replicate them locally).
Not many but some e-mail services also do outbound filtering. The above
with blacklists is inbound filtering. Your e-mail service might filter
what it sees as spam e-mail so they never get delivered. That's
something to take up with a tech call to your own e-mail provider.
However, if you do as I said in sending test e-mails to some OTHER
e-mail service on a different domain then you can test if your e-mails
are getting out from your own e-mail provider.
Then there is server-side filtering the recipient might've defined in
their e-mail account. These are filters ran up on the server for the
mailbox account there. If the user uses the webmail interface to their
e-mail account, they might see those filtered-out e-mails (if they are
moved into another folder instead of permamently deleted or discarded
which means those won't be found anywhere in the mailbox folders). If
the user is using IMAP or Deltasync to access their mailbox, they can
see all the folders (to which they subscribe) and may see your e-mail
got moved by a server-side rule into a folder other than the Inbox. If
the recipient is using POP to access their mailbox, POP has no concept
of folders and can only see the mailbox (which is the Inbox folder in
the webmail interface to the account). That means a POP user won't see
when a server-side filter has moved an e-mail out of the server-side
Inbox folder into, say, the server-side Junk, Other, or Trash folders.
A POP user has to use the webmail client to see all the folders (other
than the Inbox) in their account. For example, if a POP-using user
signs up for a forum and a confirmation e-mails gets sent where they
have to click on a URL link to complete registration for the forum
account before they can use it, the spam filter employed by the e-mail
provider might move that confirmation e-mail into the Junk folder. The
POP user won't be able to see anything in the Junk folder. They only
get to see the Inbox folder. When expecting an e-mail that doesn't
appear to arrive when using POP, the recipient has to use the webmail
interface to see if the expected e-mail got moved into another folder,
like Spam or Junk.
Then there are the client-side filters in the recipient's e-mail client
if they are using a local e-mail client versus the webmail interface to
their account. You never mentioned HOW the recipient was accessing
their e-mail. If they have rules in their e-mail client, they'll have
to check the folder where they move their e-mails. Rules that delete
e-mails don't actually delete any but instead just move them from the
Inbox folder into the Deleted Items folder (i.e., a delete rule really
is just a move rule from one folder to another). However, if their rule
permanently deletes an e-mail, it won't be found in any folder.
Permanent deletion means immediate deletion without moving a copy
anywhere.
So you'll need to have your recipient check their server-side filters in
their e-mail account and client-side rules in their e-mail client
(Outlook). Maybe they moved your e-mail into another folder. Maybe
it's in the Junk folder. I disabled Outlook spam filter but it does
come (as of 2003) with a Bayesian-type spam filter than can mistake ham
for spam and move it into the Junk folder. If the recipient has any
rules with "permanently delete" and it fired on your e-mail, they won't
have a copy of your e-mail anywhere. It may still be up on the server
in the e-mail account if the POP account was defined in the e-mail
client to NOT delete e-mails upon retrieving them from the server (i.e.,
leave POP-retrieved e-mails up on the server) or if they used IMAP to
access their e-mail account (provided their e-mail client has not yet
issued a Purge to remove delete-marked items in the e-mail client from
the original copy up on the server).
Then there are users that install anti-spam software. It may be a
separate anti-spam program (e.g., Mailwasher) or bundled in with some
security software (Norton Internet Security which has an anti-spam
module). Could be your e-mails aren't getting through that anti-spam
software.
Have the user unload Outlook. Have them disable all server-side rules
in their e-mail account (up on the server, not locally in any software).
Have them disable spam filtering up on the server for their account (if
possible; for example, you cannot disable spam filtering at Gmail).
Then send them a test e-mail along with a CC copy to yourself at some
OTHER e-mail domain. Then check if you got your test e-mail at your
other-domain e-mail service and if the recipient saw your e-mail in
their Inbox when using the *webmail* interface to their e-mail account.
that way, without spam filtering and without rules on the server for the
e-mail account, the recipient can test if your e-mails are ever reaching
his mailbox in the first place. If that works, the recipient needs to
work downward from server-side spam filtering, server-side rules,
client-side spam filtering software, client-side e-mail client and its
filtering and rules to find out at what point the e-mail that can be
received ends up getting filtered out.
