How to confim an e-mail was received?

[Jmann]

I am looking for a job. I am trying to send a mass e-mail using BCC. I am
using my gmail account, sending through outlook. I have not been getting any
responses. I am worried my e-mails are not getting through. I want to find
out if they were sent successfully. I dont want to send repeat e-mails,
bothering these companies. I have many more to send out and dont want to
waste my time. Is there a program that can monitor emails or something?
Will sending all BCC make a difference? I have also tried using the delivery
receipt. I sent to about 20 email addresses and got 2 delivery receipts
right away but none after that. Also, when sending to multiple emails, do
they all get sent at once, or do they get queued? In other words, if one
e-mail fails, will all the other e-mails waiting to be sent behind it fail?

 

[DL]

Many servers block / do not accept mail receipts
In todays job market peoples may be inundated with applications

 

[VanguardLH]

I am looking for a job. I am trying to send a mass e-mail using BCC. I am
using my gmail account, sending through outlook. I have not been getting any
responses. I am worried my e-mails are not getting through. I want to find
out if they were sent successfully. I dont want to send repeat e-mails,
bothering these companies. I have many more to send out and dont want to
waste my time. Is there a program that can monitor emails or something?
Will sending all BCC make a difference? I have also tried using the delivery
receipt. I sent to about 20 email addresses and got 2 delivery receipts
right away but none after that. Also, when sending to multiple emails, do
they all get sent at once, or do they get queued? In other words, if one
e-mail fails, will all the other e-mails waiting to be sent behind it fail?

Best is probably to send them a cover letter (your e-mail) with your
resume attached (so they can read it separate of your e-mailed cover
letter, and print it using whatever they use to view your attached
resume). Make sure you note that you would appreciate a reply; however,
unless you are targeting a known position they currently have open,
don't expect a reply from a shotgun "Got any openings?" request.

Read or delivery receipts are a *request* made by adding a header to the
outbound message. The name and value of these headers are defined by
RFC or were defined by common usage (i.e., de facto standards).

Delivery receipts are handled by the recipient's mail server and as such
provide no proof that the message was actually placed in the recipient's
final mailbox (since there may be further internal routing before
reaching the mailbox) or that the recipient was able to retrieve the
message. Few mail servers waste their resources to respond to delivery
receipt requests. They will reject a message during a mail session with
the sending mail server if they know the message is undeliverable which
results in the sending mail server issuing an NDR (Non-Deliverable
Report) message back to the sender, or they accept the message and later
issue an NDR if the message is found to be undeliverable but after the
mail session with the sending mail server was ended. They are not
interested in expending their resources to send back positive feedback
for the much higher volume of deliverable messages since the lack of the
negative feedback (reject during mail session or NDR sent later) is
itself the positive feedback.

Read receipts are handled by the recipient's e-mail client; that is, not
only must the message be delivered to and accepted by the recipient's
mail server and then get to their mailbox but the recipient must also be
able to successfully retrieve and also view the message. Retrieving the
message into the recipient's e-mail client is not sufficient to issue an
acknowledgement (receipt). The recipient must actually open or view the
message in their e-mail client. Most users will say No to a prompt to
send the acknowledgement message or they configure their e-mail client
to always ignore the request. Not all e-mail clients support read
receipt handling, especially webmail clients.

When read or delivery notifcations are requested by the sender, one of
the following headers are in the received copy of the e-mail:

Read-Receipt-To
Return-Receipt-To (for delivery receipt requests)*
Return-Receipt-Requested

Disposition-Notification-To (for read receipt requests; RFC 3798)*
Generate-Delivery-Report (for delivery receipt requests)

* Used by Microsoft Outlook.

Some are obsolete or non-standard (but may be de facto standards);
however, Microsoft has used them at some time. Only the last 2 are
standardized by RFC. These headers have as their value the e-mail
address to which the acknowledgement message (i.e., the notification or
receipt) gets sent. Because the Disposition-Notification-To header is
defined by RFC 3798 (http://www.ietf.org/html/rfc3798), so also is its
MDN (Message Disposition Notification) format, the content of the
acknowledgement, defined by that RFC. Although widely used,
Return-Receipt-To is not an RFC standard header (see
http://www.ietf.org/rfc/rfc2076.txt) but instead a de facto standard so
it may not be recognized by all e-mail clients (for those that support
read receipt handling). Also, its acknowledgement message (i.e.,
receipt) is not defined by RFC so there is no standardized format for a
delivery reciept.

RFC 3503 (http://www.ietf.org/html/rfc3503) addresses how MUAs (Mail
User Agents), like Outlook, are to handle MDNs when IMAP is involved.
However, Outlook is known to have more problems with its IMAP support
than do other e-mail clients. This RFC was ratified in 2003 but it can
take up to 6 years before e-mail clients adopt RFC standards (and only
if they choose to adopt them).

 

[Jmann]

Thanks for the help. i understand the concept of delivery and read read
receipts. I guess I need to simplify my question: One of the 20 email
recipients I sent to has been delayed. Will this delay the other recipients
from receiving the e-mail, or cause them to fail to reach the destination?

 

[VanguardLH]

Thanks for the help. i understand the concept of delivery and read read
receipts. I guess I need to simplify my question: One of the 20 email
recipients I sent to has been delayed. Will this delay the other recipients
from receiving the e-mail, or cause them to fail to reach the destination?

When you send an e-mail, your client compiles an aggregate list of
recipients from the To, Cc, and Bcc fields in its UI. For each
recipient in that list, it issues a RCPT-TO command to your outbound
e-mail server. That is followed by 1 DATA command that contains the
content of your message (the headers in your client's UI along with the
body of your message; i.e., the data = user headers + user body). So if
you sent to 20 recipients, the e-mail client will send 20 RCPT-TO
commands followed by 1 DATA command. The mail server then proceeds to
send that one copy of message's data to each recipient. Each copy of
your e-mail that gets sent out is independent of the other copies.
Think of it like a copy machine: one message in, N copies out (and jams
on a particular copy won't jam the others).

If there is a problem in sending a particular copy of your e-mail, you
should get an error status back while your e-mail client is sending
commands to your outbound mail server (i.e., during the mail session) or
you later get back NDRs (non-delivery reports) as e-mails telling you of
a problem with delivery. It is possible that some problem on the mail
server results in some or none of your e-mails getting sent but you have
no control over the mail server nor access to its operational logs.

A trick to check if your mail server is sending out your e-mails (but
not how many copies, just if ANY are getting sent) is to Bcc yourself on
the critical e-mails. Do NOT send the Bcc'ed copy to your own e-mail
account. The mail server may see that you are sending to yourself and
simply short-circuit the process to dump the message right back into
your mailbox without ever actually going through the mail server's
mailing process. Also do NOT send the Bcc'ed copy to yourself for
another account with the same e-mail provider from where you are sending
your e-mails. Again, internal routing may short-circuit the procedure
so the message gets dumped into your mailbox without ever using the
externally-facing (boundary) mail servers that go out from their network
to connect to other off-domain SMTP mail servers. Use another e-mail
account of yours that is with another e-mail provider on a different
domain. When you send the critical e-mails, Bcc yourself at that
off-domain account. When you get a copy in that off-domain account, you
know that your sending mail server actually did go through the process
of sending your e-mails. Think of like using the inter-departmental
mail services but you are sending a letter inside the big envelope to an
outsider. Mailing services makes a copy of your letter along with
sending out copies to where you told them to send those copies. You
getting back a copy lets you know that they did *something* to send out
copies of your letter.

 

[Brian Tillman [MVP - Outlook]]

Thanks for the help. i understand the concept of delivery and read read
receipts. I guess I need to simplify my question: One of the 20 email
recipients I sent to has been delayed. Will this delay the other recipients
from receiving the e-mail, or cause them to fail to reach the destination?

Failure to send to one recipient should not affect delivery to the others.