Chris Boorman said:
I'd like to find a way to implement a rule that automatically moves
incoming messages to a folder if they follow a thread that I'm not
really interested in, but that I like to keep in a folder for
reference. I.e., if I see that several messages are trickling into my
Inbox that are all responses to a message I've already moved, then
I'd like to flag the thread with a move rule.
Does anyone know of a way I can implement this kind of functionality?
Thanks,
Chris.
The References header (used to list the Message-ID of the original
message and any references it had) is not a required header. It may
appear zero or one times. See RFC 2822, Internet Message Format.
Without the References header to string together the messages, the
client would have to use the Subject header (and ignore a leading "Re: "
prefix, if it exists) which means unrelated messages may get combined
under a thread. It is unclear when using "Group by Conversation" if the
conversation is grouped by the References header (with a fallback to the
Subject header) or just by the Subject header. However, when defining a
view, you can select to group by Conversation or to group by Subject so
there must be some difference (under the assumption that group by
Subject actually ignores any leading "Re: " prefix).
If you want to base the thread on the Subject header and it's a
particular message that you want to move out to some other folder, then
why not just define a rule that looks for that string in the Subject
header and move a message that has it?
You could also use a rule to assign a category to a message and then
move it, then define a view for your destination folder that groups by
categories.
The thread view is only within a particular folder, not by searching for
all messages across all folders to see where they might be and then
somehow decide into which folder to yank them all. Views are specific
to the folder they are are employed. You'll have to move the message
into whatever folder you want to implement a thread view (i.e., group by
conversation). If you don't get a reliable move from a rule that is
based on a string in the Subject header, you could try a rule that is
based on the References header. You'll have to get the Message-ID from
the first message and then test for "References: <originalreference". I
believe the References header looks like "References:
<origref[,nextref[,nextnextref[,...]>", where each square-bracketed
portion is optional (i.e., the list gets longer as more references are
added with each reply). Outlook has the clause "where 'string' is in
message header" but it is a substring search and which doesn't let you
specify the header to look in (so it doesn't look for a substring
somewhere within a particular header). That means you have to include
the header's name in the string. The original reference (of the
message-id of the original message) should be the first one listed in
the reply and why I figure you would have to use:
with "References: <garblestring@host" in message headers
This all means you know what the message-ID is for the original message.
The References header is optional and few of my e-mails (replies from
others to my messages) include it. Well, guess what? The Message-ID
header is optional, too. So defining a rule to test on the optional
Message-ID from the original message to appear as the first one listed
in the optional References header is getting really iffy that it will
work. That's why I suspect that group by Conversation would have to
effectively revert to group by Subject since it is doubtful that the
References header exists in all replies and the Message-ID may have
never been available in the first place to keep track of in the
References header.
For usenet posts, the References header is required (as per RFC 1036,
section 2.1.4 and 2.2.5) so grouping is much more reliable. Not true
for e-mail. For example, I sent an e-mail which had "Message-ID:
<myOrigID@myhost>". The recipient replied and added the "References:
<myOrigID@myhost>" so there was a link back to mine. Their reply also
had its own "Message-ID: <theirReplyID@theirhost>". When I got their
reply, I replied to it which added "Message-ID" <myNextID@myhost>".
However, Outlook did *not* add a References header. All it added was
the "In-Reply-To: <theirReplyID@theirhost>". That breaks the tracking
chain and only the immediate message to which I replied got identified
(i.e., the chain got broke so you could only look back 1 link). If
Outlook had added the References header to this 2nd reply (my first
reply to their reply), it would've looked like "References:
<myOrigID@myhost,theirReplyID@theirhost>" (so their next reply would
have "References:
<myOrigID@myhost,theirReplyID@theirhost,myNextID@myhost>"). I suppose
it is possible that Outlook could rebuild the chain using the single
backward reference in the In-Reply-To header, look for a message that
has that as its Message-ID, and then follow back some more through that
other messages's one backward link via the In-Reply-To header, and so on
until it got to the message whose Message-ID matched the value in a
In-Reply-To header. However, and yes again, the In-Reply-To header is
also optional. Argh! There are a lot of "SHOULD" statements in the
RFCs that never get implemented or their implementation is erratic.
There has been too much that has been left as optional in the RFCs.
You'll probably get lost in the message IDs and chaining them, and
Microsoft has yet to support regular expressions in the rules (and
wildcarding support is minimal where it is supported and often doesn't
allow multiple wildcards), so I suspect your rule will simply be:
with 'specificwords' in Subject
(which should be changed for accuracy to be "with <specificphrases> in
Subject"). You'll have to decide what to test on for which messages to
move into which folder and then enable the "Group by Conversation" view
in that folder.
