Freda said:
I have sent emails but unfortunately misspelled their email address. However,
I did not get an "undelivered report" advising me that my email was not sent.
How do I go about getting this "undelivered report" being sent to me in
future.
Your sending mail server will issue an NDR (non-delivery report) as an
e-mail sent to your mailbox if, for example, the domain is invalid. If
you misspell the domain then your sending mail server can't find it to
make a connection. Your sending mail server will send you an NDR
telling you about the invalid domain.
When your sending mail server connects to and establishes a mail session
with the receiving mail server, it issues a RCPT-TO command to specify
the recipient of your e-mail. If the receiving mail server rejects that
command with an -ERR status ("no such user") then your sending mail
server gets that error. Your sending mail server then sends you an NDR
stating that the receiving end doesn't have a user by the name you
specified.
If the receiving mail server accepts your e-mail from your sending mail
server and ends the mail session, your sending server is done with its
transmission and was told the send operation was successful. If the
receiving mail server is misconfigured to check if the e-mail is
deliverable after the mail session is over, the receiving mail server
will send back an NDR back to your account stating "no such user" or
whatever was the belated delivery error. Properly configured mail
servers should check if the account exists DURING the mail session and
not afterward, especially because there is nothing in the received
e-mail that guarantees the identity of the sender to ensure the NDR is
delivered back to the proper sender. Only during the mail session does
the receiving mail server absolutely know the host (sending mail server)
that connected to it and should issue an -ERR status at that time. If
the receiving mail server accepts the e-mail, ends the mail session, and
then check for deliverability, it only has the headers in the e-mail to
determine who was the sender and that information can be bogus (since
the sender's e-mail client added that info and spammers obviously are
not going to identify themselves). I haven't bothered to investigate
SPF (Sender Policy Framework) used by the sending mail server to know if
the receiving mail server would know for sure where to send back its
NDR. So if the receiving mail server doesn't check for deliverability
until after the mail session is over with the sending mail server, it
sends the NDR based on the headers in the received e-mail.
We don't know from where the NDR originated. Its Received headers will
tell you if your sending mail server deposited it into your account or
if the receiving mail server sent a new e-mail to your mailbox as the
NDR. In any case, unless you are administering one of the mail server,
you have absolutely no control over how they operate. In fact, your
sending mail server may have successfully transmitted your e-mail to the
receiving mail server which sent back an +OK status, but it was
somewhere at the receiving end that the e-mail disappeared.
You never bothered to identify the recipient's domain, if the problem
exists at just one domain, or if your e-mails vanish to recipients at
different domains. Hotmail, for example, is well known to accept
e-mails which then vanish into the ether. The e-mail got accepted but
it never shows up in the recipient's mailbox. It is not an issue with
the spam filter settings up on the server or server-side rules moving
the new e-mail into some other folder than expected (POP, for example,
can only see the Inbox folder). It never arrived into the recipient's
mailbox for any spam filter or rules to act upon it. In fact, Microsoft
published a web site (
http://postmaster.msn.com/) to help postmasters at
other domains help ensure that this disappearance doesn't happen but
it's not a guarantee. Also, Hotmail is known to use their own blacklist
of known spam sources but sometimes fails to send back an NDR noting the
rejection (which should've been done DURING the mail session rather than
afterward).
You could Bcc yourself to a domain other than your current e-mail
provider. That is, if using your ISP to send e-mails, open a free
account at Gmail, Yahoo, or even Hotmail. Do not use your own account
to Bcc yourself a copy of your test e-mail. The boundary mail servers
won't get involved and instead internal routing will be used to deposite
your outbound e-mail right back into your mailbox. You need to send to
a different domain to ensure their boundary mail servers get involved.
Then send your test e-mail to those recipients that are not getting your
e-mails but also Bcc yourself at your other-domain account. If you get
the Bcc copy but your recipients do not then the problem is on their end
and, again, you have no control over how their e-mail server works or
that recipient's spam and rules configuration on the server or how they
configured their e-mail client. If you don't get the Bcc copy in your
other-domain account then you known your own sending mail server never
transmitted your e-mail that it accepted successfully from your e-mail
client, so you could then show your e-mail provider that they have a
problem.
