rule for "Your Message " messages.

  • Thread starter Thread starter John G
  • Start date Start date
J

John G

Is it possible to make a rule to move the "Your Message "
that is generated when your message is read to another folder.

Outlook 2003 XPSp2.

John G .
 
Is it possible to make a rule to move the "Your Message " that is
generated when your message is read to another folder.

Outlook 2003 XPSp2.
Click to expand...

Are you talking about read receipts?
 
you could but tracking on the sent item may not be updated.









** Please include your Outlook version, Account type, and Windows Version
when requesting assistance **
 
Pray tell ! How.

And if the message has been recived what tracking is there that I could not
do by looking in the folder where I would like a rule to put them all.

John G.
 
John said:
Pray tell ! How.

And if the message has been recived what tracking is there that I could not
do by looking in the folder where I would like a rule to put them all.
Click to expand...

What happens when you define a rule to handle those e-mails that are
read receipts that you requested the recipient to send back to you?

The read receipt *request* is a header that gets added to your outbound
e-mail. The recipient's e-mail client has to recognize the header and
then send back a new e-mail as the read reciept. While the header is
well defined, what comprises a read receipt e-mail sent back to you is
not. The recipient can send anything back they want as the read
receipt. Normally the user gets stuck with whatever their e-mail
program hardcoded to send back as the new e-mail for the read receipt
but that doesn't eliminate users that can use scripting to manufacture
their own read receipt e-mails and obviously different e-mail programs
may compose a different new e-mail as their read receipt that they send
back to you. So you end up creating a rule in which you will have to OR
several strings as you continue receiving back the read receipts to
handle whatever they choose to send back to you. There isn't a standard
header that they can add to their new e-mail that identifies that it is
an acknowlegement to your request (for a read receipt).

Since many anti-spam programs can strip out the read receipt header from
inbound e-mails, and since most users soon disable read receipts after
getting the first few, using read receipts is mostly a waste of time
unless you are in a closed environment where you can force all
recipients to keep read receipts enabled, like in a company where its
policy dictates that read receipts will be honored for company e-mail;
however, it is likely that they strip out the read receipt header for
inbound e-mails that come from the outside since they don't want their
employees sending them outside the company.
 
when a read receipt is requested, the sent item updates with read/unread
information contained in the receipt. You just need to look at the sent item
to see if the recipient read it, not browse a folder looking for the
matching receipt as moving these message will not allow the sent item to
update.

what rules have you tried so far?
 
VanguardLH said:
What happens when you define a rule to handle those e-mails that are
read receipts that you requested the recipient to send back to you?

The read receipt *request* is a header that gets added to your outbound
e-mail. The recipient's e-mail client has to recognize the header and
then send back a new e-mail as the read reciept. While the header is
well defined, what comprises a read receipt e-mail sent back to you is
not. ...
Click to expand...

Well, I was correct on the first point that the MDN (message disposition
notification) request is enacted by adding a header, which is the
"Disposition-Notification-To" header. However, I was wrong in that
there is no standard on the content of the reply (well, there isn't
regarding the content but there regarding headers defining that
content). RFC 2298 (ftp://ftp.rfc-editor.org/in-notes/rfc2298.txt)
describes MDNs. While a header is used to ask for the reply (read
receipt), a header is used but not specifically as the read receipt
itself. Instead a MIME header is added that defines the MIME part in
the body of the email as the disposition report (read receipt). That
is, the returned email has a MIME part in it that comprises the
notification (that you can read) but that MIME part includes headers
that identify there is that MIME part in the body, so indirectly there
are headers on which you can test if an e-mail is a read receipt.

When I send an email with a read receipt, the following header gets
added to that outbound e-mail:

Disposition-Notification-To: "myName" <myEmailAddress>

When I receive that email and elect to send a read receipt, a new email
gets composed and sent that has the following in the header and body
sections:

Header section:

Content-Type: multipart/report;
report-type=disposition-notification;

Body section (in MIME part's headers):

Content-Type: message/disposition-notification

Since the MIME content is adequately defined in the headers, there is no
reason to include testing the body section for the "Content-Type:
message/disposition-notification" string. Besides, the content of that
MIME part is at the whim of the sender's e-mail program (although that
line must still appear to define that MIME part's type). Just define a
rule that looks in the message headers for BOTH the "Content-Type:
multipart/report;" and "report-type=disposition-notification;" lines.
So the rule in Outlook might look something like:

Apply this rule after the message arrives
with 'Content-Type: message/disposition-notification' in the body
and with 'report-type=disposition-notification' in the message header
<whatever action clause(s) you want to commit on that message>
<recommended 'stop processing more rules' clause>

Testing on just the "report-type" header line is probably sufficient (so
you could delete testing for the string in the body of the message).

I haven't bothered with using or sending read receipts in m-a-n-y years.
In fact, my anti-spam program will strip out the read receipt headers so
I never have to bother with them in case I forget to configure my e-mail
client to NEVER send read receipts. I had to disable that filtering to
do the testing above. I thought Outlook would get the receipt e-mail
and then update its message store (a database) to record that a read
receipt was delivered and that status change was on the record for the
original message that you sent that requested the receipt. In other
words, once the receipt got accepted by your Outlook client, it wasn't
needed anymore because the status of the original message sent out got
updated. However, as I recall, you had to actually open the read
receipt e-mail to read it which then got the record updated for the
original message to have its status updated to reflect that you got a
read receipt for it. There is some chance, probably good, that if you
move them out of the Inbox that reading them in another folder will not
get Outlook to update the status for the original e-mail. If you aren't
going to read those read receipts that YOU requested then why bother
requesting them?

I don't see why you even want to keep the read receipt e-mails after you
have read them. If the status of the original e-mail gets updated, why
keep the fluff?
 
VanguardLH said:
Well, I was correct on the first point that the MDN (message disposition
notification) request is enacted by adding a header, which is the
"Disposition-Notification-To" header. However, I was wrong in that
there is no standard on the content of the reply (well, there isn't
regarding the content but there regarding headers defining that
content). RFC 2298 (ftp://ftp.rfc-editor.org/in-notes/rfc2298.txt)
describes MDNs. While a header is used to ask for the reply (read
receipt), a header is used but not specifically as the read receipt
itself. Instead a MIME header is added that defines the MIME part in
the body of the email as the disposition report (read receipt). That
is, the returned email has a MIME part in it that comprises the
notification (that you can read) but that MIME part includes headers
that identify there is that MIME part in the body, so indirectly there
are headers on which you can test if an e-mail is a read receipt.

When I send an email with a read receipt, the following header gets
added to that outbound e-mail:

Disposition-Notification-To: "myName" <myEmailAddress>

When I receive that email and elect to send a read receipt, a new email
gets composed and sent that has the following in the header and body
sections:

Header section:

Content-Type: multipart/report;
report-type=disposition-notification;

Body section (in MIME part's headers):

Content-Type: message/disposition-notification

Since the MIME content is adequately defined in the headers, there is no
reason to include testing the body section for the "Content-Type:
message/disposition-notification" string. Besides, the content of that
MIME part is at the whim of the sender's e-mail program (although that
line must still appear to define that MIME part's type). Just define a
rule that looks in the message headers for BOTH the "Content-Type:
multipart/report;" and "report-type=disposition-notification;" lines.
So the rule in Outlook might look something like:

Apply this rule after the message arrives
with 'Content-Type: message/disposition-notification' in the body
and with 'report-type=disposition-notification' in the message header
<whatever action clause(s) you want to commit on that message>
<recommended 'stop processing more rules' clause>

Testing on just the "report-type" header line is probably sufficient (so
you could delete testing for the string in the body of the message).

I haven't bothered with using or sending read receipts in m-a-n-y years.
In fact, my anti-spam program will strip out the read receipt headers so
I never have to bother with them in case I forget to configure my e-mail
client to NEVER send read receipts. I had to disable that filtering to
do the testing above. I thought Outlook would get the receipt e-mail
and then update its message store (a database) to record that a read
receipt was delivered and that status change was on the record for the
original message that you sent that requested the receipt. In other
words, once the receipt got accepted by your Outlook client, it wasn't
needed anymore because the status of the original message sent out got
updated. However, as I recall, you had to actually open the read
receipt e-mail to read it which then got the record updated for the
original message to have its status updated to reflect that you got a
read receipt for it. There is some chance, probably good, that if you
move them out of the Inbox that reading them in another folder will not
get Outlook to update the status for the original e-mail. If you aren't
going to read those read receipts that YOU requested then why bother
requesting them?

I don't see why you even want to keep the read receipt e-mails after you
have read them. If the status of the original e-mail gets updated, why
keep the fluff?
Click to expand...

Thank you for your informative reply that will take me a while to absorb.

I only asked this question because I tried to make a rule and discovered the
Create a Rule Icon is greyed out for Read Receipts and some other Message
types.

I have tried to find the definition of the various Icons in the Icon column
but have been unsuccessful and it does not seem that it can be changed to
text..

How can you tell if the Status of the original msg was updated? or is that
the little I in the Icon of the original message.

John G.
 
Diane Poremsky said:
when a read receipt is requested, the sent item updates with read/unread
information contained in the receipt. You just need to look at the sent
item to see if the recipient read it, not browse a folder looking for the
matching receipt as moving these message will not allow the sent item to
update.

what rules have you tried so far?
Click to expand...



I only asked this question because I tried to make a rule and discovered the
Create a Rule Icon is greyed out for Read Receipts and some other Message
types.

I have tried to find the definition of the various Icons in the Icon column
but have been unsuccessful and it does not seem that it can be changed to
text..

How can you tell if the Status of the original msg was updated? or is that
the little I in the Icon of the original message.

John G.
 
That's only for the automatic creation - copy the subject and make a rule
based on the subject.









** Please include your Outlook version, Account type, and Windows Version
when requesting assistance **
 
I have no idea - I'm guessing because the receipt is a special message that
needs to remain in the inbox to process. Or because its an administrator
message. Or something like that. :)









** Please include your Outlook version, Account type, and Windows Version
when requesting assistance **
 
John said:
How can you tell if the Status of the original msg was updated? or is that
the little I in the Icon of the original message.
Click to expand...

As I mentioned, I haven't bothered sending read receipts for years and
have do not sent read receipts myself. Only once did I have to enable
them at a company that I worked at sometime around 8 years ago. My
recollection is that when you view the item in the Sent Items folder (or
wherever it got stored depending on your Outlook configuration), there
was a yellow infobar, header, or something added to the sent copy of the
message that informed you that the status of that item had been updated
to reflect that a read receipt had been received.

When you look at an item in your Sent Items folder for which you have
received (and viewed) a read receipt, there isn't any information
displayed along with that sent item to indicate that it got the read
receipt that you requested and received?

If just an icon is displayed, some of them are described at:

http://www.howto-outlook.com/Howto/icons.htm

There is one there described as "Message Holds (Receipts) Information
Tab". Do you see that icon? If so, apparently there is supposed to be
a tab added to the message to show the read receipt information.
 
Back
Top