how to change what text and feilds r sent as a "return Receipt"

[Splash]

Would like to change what is sent when I send a Return Receipt to someone.
can't seem to find this anywhere i any documentation

 

[VanguardLH]

Would like to change what is sent when I send a Return Receipt to someone.
can't seem to find this anywhere i any documentation

The sender of an e-mail with the headers requesting a "read/delivery
receipt" cannot specify how that acknowledgement e-mail is composed.

 

[Splash]

Ok, Where is this information pulled from? At two locations email is sent and
recieved. when sent from M1 a reead receipt is requested. At M2 the message
is received and subsequently asked to send read receipt. At this point the
reader tick the "ok to send read receipt" and the receipt is sent. The reason
I ask, is that prior the "read receipt" contained information on the email
that is being receipted, like the subject, date and time, and some verbage
regarding what the read receipt meant. Now, the body contains nothing. Where
is this controlled?

 

[Brian Tillman [MVP-Outlook]]

Ok, Where is this information pulled from? At two locations email is sent
and
recieved. when sent from M1 a reead receipt is requested. At M2 the message
is received and subsequently asked to send read receipt. At this point the
reader tick the "ok to send read receipt" and the receipt is sent. The
reason
I ask, is that prior the "read receipt" contained information on the email
that is being receipted, like the subject, date and time, and some verbage
regarding what the read receipt meant. Now, the body contains nothing. Where
is this controlled?

Prior to what? As far as I can tell, there is no method of controlling what's
in the read receipt.

 

[VanguardLH]

Ok, Where is this information pulled from? At two locations email is sent and
recieved. when sent from M1 a reead receipt is requested. At M2 the message
is received and subsequently asked to send read receipt. At this point the
reader tick the "ok to send read receipt" and the receipt is sent. The reason
I ask, is that prior the "read receipt" contained information on the email
that is being receipted, like the subject, date and time, and some verbage
regarding what the read receipt meant. Now, the body contains nothing. Where
is this controlled?

Only the headers for requesting a read/delivery receipt are defined.
Nothing is defined as to the content of the new e-mail that gets sent by the
recipient back to the sender as the acknowledgement of that request (i.e.,
the recipient's e-mail client determines what to put into the new e-mail
sent to the sender as the "read receipt"). The recipient's e-mail client
decides what to put into the new e-mail sent back to you as the receipt.
You never identified what the recipient uses for their e-mail client, and
outside a controlled test or work environment then you won't know.

Read receipt *requests* (which is a header in the e-mail) are handled by the
recipient's e-mail client. Whether the e-mail client prompts, always sends,
or always ignores these requests depends on how the user configured their
e-mail client. The default in most e-mail clients is to prompt when a
sender has requested a read receipt. This prompt usually spurs the user to
configure their e-mail client to ignore all such further requests as they
are not interested in divulging to the sender as to if and when they read
the sender's e-mail.

Delivery receipt *requests* (which is a header in the e-mail) are handled by
the recipient's mail host (NOT by the recipient's e-mail client). It is a
request for the receiving mail host to notify the sender that their e-mail
got to the recipient's mail service. It does NOT validate that the e-mail
got through that mail service to the recipient's mailbox and it is does not
validate that the recipient retrieved the e-mail in their e-mail client and
then opened that e-mail. Rare few mail hosts waste their time with positive
feedback via delivery receipts. They don't need to tell you when your
e-mail was accepted by their mail host. Instead they send back negative
feedback when their mail host rejects or otherwise will not or can not
accept your e-mail. The lack of negative feedback is the positive feedback.
Mail hosts don't need to waste their time validating all accepted e-mails
and instead they just need to provide the negative feedback when they cannot
accept your e-mail (or the sending mail host sends back the negative
feedback when it cannot connect to the receiving mail host).

Read receipts: Requests are handled by recipient's e-mail client.
Most users ignore all such requests.
Delivery receipts: Requests are handled by the receiving mail host.
Most mail hosts ignore such requests.

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).

 

[Carmel]

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).

That URL is deprecated or broken, take your pick.

http://www.faqs.org/rfcs/rfc3503.html

For the record, Microsoft takes 6 years or more to include RFC
standards (if they ever do at all). FOSS usually implements the
recomendations in 6 months or less.

--
Carmel

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__________________________________________________________________

Preserve Wildlife! Throw a party today!

 

[VanguardLH]

That URL is deprecated or broken, take your pick.

http://www.faqs.org/rfcs/rfc3503.html

Or http://www.rfc-editor.org/rfc/rfc3503.txt. Apparently IETF changed the
path to its RFC docs, so I updated my stored reply to reflect using
rfc-editor.org's doc paths. Thanks for the update.

For the record, Microsoft takes 6 years or more to include RFC
standards (if they ever do at all). FOSS usually implements the
recomendations in 6 months or less.

Which e-mail clients designed to run as a native application under Windows
are FOSS programs? Of the non-FOSS and non-Microsoft e-mail clients for
Windows, how long was it before they adopt the RFC standards on average?
I've never seen any of those adopted within 6 months.

How many e-mail clients (MUAs) still default to using port 25 for SMTP
connections? RFC 2476 was ratified back in 1998 specified to use port 587
for MUAs? In my last trial of 8 e-mail clients for Windows a few months
back, all of them were still defaulting to port 25. Some ISPs adopted port
587 for client connects to the SMTP server about 3 years afterward, some not
until 6 years later, and still some haven't switched. Meanwhile the e-mail
clients haven't switched to defaulting to port 587.

Just because IETF got around to ratifying an RFC after the year(s) it spent
as a draft doesn't mean anyone will or must comply. Although RFC 3798,
section 3, comes close to defining the MDN format, it doesn't set in
concrete a specific format, require all content, and doesn't have to be
complied by any MUA in what it composes as its MDN. My understanding of RFC
3798 is as a general guide on how any auto-responder will compose its reply.
This includes challenge-response schemes, vacation responders, etc, and not
just applicable to read/delivery receipt notices (i.e., acknowledgement
e-mails sent back to the sender that requested the notification).

As yet, I haven't found or been told of an RFC that dictates in something
like BNF format showing just exactly what is to be contained in the MDN
e-mails sent to the party asking for the receipt. There might be one but,
as yet, I don't know of one. Maybe someone else has a better RFC that
actually delineates just exactly what MUST contained in a "read receipt"
e-mail (along with assuming that any or some e-mail clients actually comply
with this other RFC or even with RFC 3798). RFCs are just guidelines, not a
group of federal mashalls with carte blanche to shoot anyone that doesn't
comply.

 

[Splash]

Or http://www.rfc-editor.org/rfc/rfc3503.txt. Apparently IETF changed the
path to its RFC docs, so I updated my stored reply to reflect using
rfc-editor.org's doc paths. Thanks for the update.


Which e-mail clients designed to run as a native application under Windows
are FOSS programs? Of the non-FOSS and non-Microsoft e-mail clients for
Windows, how long was it before they adopt the RFC standards on average?
I've never seen any of those adopted within 6 months.

How many e-mail clients (MUAs) still default to using port 25 for SMTP
connections? RFC 2476 was ratified back in 1998 specified to use port 587
for MUAs? In my last trial of 8 e-mail clients for Windows a few months
back, all of them were still defaulting to port 25. Some ISPs adopted port
587 for client connects to the SMTP server about 3 years afterward, some not
until 6 years later, and still some haven't switched. Meanwhile the e-mail
clients haven't switched to defaulting to port 587.

Just because IETF got around to ratifying an RFC after the year(s) it spent
as a draft doesn't mean anyone will or must comply. Although RFC 3798,
section 3, comes close to defining the MDN format, it doesn't set in
concrete a specific format, require all content, and doesn't have to be
complied by any MUA in what it composes as its MDN. My understanding of RFC
3798 is as a general guide on how any auto-responder will compose its reply.
This includes challenge-response schemes, vacation responders, etc, and not
just applicable to read/delivery receipt notices (i.e., acknowledgement
e-mails sent back to the sender that requested the notification).

As yet, I haven't found or been told of an RFC that dictates in something
like BNF format showing just exactly what is to be contained in the MDN
e-mails sent to the party asking for the receipt. There might be one but,
as yet, I don't know of one. Maybe someone else has a better RFC that
actually delineates just exactly what MUST contained in a "read receipt"
e-mail (along with assuming that any or some e-mail clients actually comply
with this other RFC or even with RFC 3798). RFCs are just guidelines, not a
group of federal mashalls with carte blanche to shoot anyone that doesn't
comply.
.

Thanks all for the responses.
Brian: M1 and M2 are using Outlook. And the prior to is that one day It was
ther the next it was not. No additions or other changes that were done to the
M2 other than the "normal" MS Update services and AV services.

I request automatically read receipts for all my mail. Just a matter of
course. I receive many and varied receipts containing many differnt
configurations of info about the email and signature type verbage and
disclaimers. they all appear to be read reciets not replies. So, this leads
me to believe that it (the MDN) is configurable, but where.