Outlook Regions

S

SpiderBin

I orginally wrote about this on my blog
(http://spiderbin.com/archive/2005/01/08/204.aspx) and today I found out
about this site from Mark Bowers blog
http://blogs.msdn.com/bowerm/archive/2005/01/04/346183.aspx?Pending=true.

Here's my post:
Suggestion for Microsoft to improve Outlook productivity
I've got an idea; I'd call it Regions...



Wouldn't it be nice when typing an email if you could identify specific
regions of that email which are for the eyes of thisperson[at]my[dot]com &
thatperson[at]my[dot]com

and not theotherperson[at]my[dot]com, even though all 3 persons need to be
on the thread?



Sorta like this:



TO: thisperson[at]my[dot]com, thatperson[at]my[dot]com,
theotherperson[at]my[dot]com

SUBJECT: Region Sample

BODY:



<region users=" thisperson[at]my[dot]com, thatperson[at]my[dot]com">

The contents of this region would not be seen by theotherperson[at]my[dot]com

</region>



But this global bit of information would be seen by everyone.



<region users=" theotherperson[at]my[dot]com">Don't worry theotherperson we
still like you</region>
 
M

Milly Staples [MVP - Outlook]

I would never use it as it would be more of a hassle than a time-saver.

And blogs are on my major ignore list.


--
Milly Staples [MVP - Outlook]

Post all replies to the group to keep the discussion intact. Due to
the (insert latest virus name here) virus, all mail sent to my personal
account will be deleted without reading.

After furious head scratching, SpiderBin asked:

| I orginally wrote about this on my blog
| (http://spiderbin.com/archive/2005/01/08/204.aspx) and today I found
| out about this site from Mark Bowers blog
| http://blogs.msdn.com/bowerm/archive/2005/01/04/346183.aspx?Pending=true.
|
| Here's my post:
| Suggestion for Microsoft to improve Outlook productivity
| I've got an idea; I'd call it Regions...
|
|
|
| Wouldn't it be nice when typing an email if you could identify
| specific regions of that email which are for the eyes of
| thisperson[at]my[dot]com & thatperson[at]my[dot]com
|
| and not theotherperson[at]my[dot]com, even though all 3 persons need
| to be on the thread?
|
|
|
| Sorta like this:
|
|
|
| TO: thisperson[at]my[dot]com, thatperson[at]my[dot]com,
| theotherperson[at]my[dot]com
|
| SUBJECT: Region Sample
|
| BODY:
|
|
|
| <region users=" thisperson[at]my[dot]com, thatperson[at]my[dot]com">
|
| The contents of this region would not be seen by
| theotherperson[at]my[dot]com
|
| </region>
|
|
|
| But this global bit of information would be seen by everyone.
|
|
|
| <region users=" theotherperson[at]my[dot]com">Don't worry
| theotherperson we still like you</region>
 
V

Vanguard

SpiderBin said:
I orginally wrote about this on my blog
(http://spiderbin.com/archive/2005/01/08/204.aspx) and today I found
out
about this site from Mark Bowers blog
http://blogs.msdn.com/bowerm/archive/2005/01/04/346183.aspx?Pending=true.

Here's my post:
Suggestion for Microsoft to improve Outlook productivity
I've got an idea; I'd call it Regions...

Wouldn't it be nice when typing an email if you could identify
specific
regions of that email which are for the eyes of
thisperson[at]my[dot]com &
thatperson[at]my[dot]com

and not theotherperson[at]my[dot]com, even though all 3 persons need
to be
on the thread?

Sorta like this:

TO: thisperson[at]my[dot]com, thatperson[at]my[dot]com,
theotherperson[at]my[dot]com

SUBJECT: Region Sample

BODY:
<region users=" thisperson[at]my[dot]com, thatperson[at]my[dot]com">
The contents of this region would not be seen by
theotherperson[at]my[dot]com
</region>

But this global bit of information would be seen by everyone.

<region users=" theotherperson[at]my[dot]com">Don't worry
theotherperson we
still like you</region>

So how does that stop all or any recipients from simply looking at the
HTML source code to see the part that you attempting to hide only in the
rendered version? You do know that lots of e-mail clients that are
configured to read in text-only mode may show a text version of your
HTML-formatted e-mail?

An HTML-formatted message *SHOULD* (but is not required to) contain both
a
plain-text MIME part and an HTML MIME part. For users of e-mail clients
that don't understand HTML or have been configured to read in plain-text
mode, they still have a plain-text MIME part that is readable and
displayed. Sending
HTML-formatted e-mails without a plain-text MIME part can raise the
threshold that the message gets tagged as spam and never delivered to
the recipient. A "good" HTML-formatted e-mail should look like in the
body of the message:

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C4F70D.B47E5430
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

<plain-text version of the message>

------=_NextPart_000_0001_01C4F70D.B47E5430
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<HTML version of the message>

So if you send an HTML-formatted e-mail without the plain-text MIME
part, expect to raise the chances your message gets detected as spam.
By not including a plain-text MIME part, some e-mail clients will then
use a converter to show the HTML part as plain text (sans tags) so they
may not see the portion you have enclosed within the <region></region>
tag pair, or they might see it if the converter doesn't handle that tag
pair or if the e-mail client doesn't provide a converter and just shows
all the HTML (which is, after all, just plain text even for the tags and
everything else in the message).

So they might not see your <region> part in an HTML-formatted message
but they can look at the source to see it. They might not see the
region part if their e-mail's HTML-to-text converter omits that part but
it is unlikely for quite awhile (until the HTML spec gets updated to
define such a tag). They might see the region part if there was no
plain-text MIME part (but then ALL recipients reading in plain-text mode
would not see the region part).

It won't work. Users still get to see ALL of the message when viewing
it in raw mode. Users have become quite used to looking at the source
code for the HTML due to phishing attempts using <A> tags that show one
URL as the text rendered in the HTML document but the real URL is
something else. If they export the HTML-formatted e-mail, its content
will just be all the text contained within the HTML-formatted e-mail,
and HTML is just plain-text, too, so they can see it that way.

Send different messages if you want the recipients to see different
messages. Or use a bulk e-mail program that will insert some content
based on one list of recipients and different content based on a
different list of recipients. I think even Word's Mail Merge could do
that. Once you send your message, you are no longer in control over
what the recipient sees in it or how they can use it. Users are getting
smarter because spammers and phishers are forcing them to get smarter.
Trying to hide content within the HTML coding of an e-mail won't hide it
from them looking at it.
 
S

SpiderBin

I'm not suggesting that it would hidden in HTML. It's obvious that won't
work. An idea like Regions would have to be implemented within in the
Exchange Server.

SpiderBin

Vanguard said:
SpiderBin said:
I orginally wrote about this on my blog
(http://spiderbin.com/archive/2005/01/08/204.aspx) and today I found
out
about this site from Mark Bowers blog
http://blogs.msdn.com/bowerm/archive/2005/01/04/346183.aspx?Pending=true.

Here's my post:
Suggestion for Microsoft to improve Outlook productivity
I've got an idea; I'd call it Regions...

Wouldn't it be nice when typing an email if you could identify
specific
regions of that email which are for the eyes of
thisperson[at]my[dot]com &
thatperson[at]my[dot]com

and not theotherperson[at]my[dot]com, even though all 3 persons need
to be
on the thread?

Sorta like this:

TO: thisperson[at]my[dot]com, thatperson[at]my[dot]com,
theotherperson[at]my[dot]com

SUBJECT: Region Sample

BODY:
<region users=" thisperson[at]my[dot]com, thatperson[at]my[dot]com">
The contents of this region would not be seen by
theotherperson[at]my[dot]com
</region>

But this global bit of information would be seen by everyone.

<region users=" theotherperson[at]my[dot]com">Don't worry
theotherperson we
still like you</region>

So how does that stop all or any recipients from simply looking at the
HTML source code to see the part that you attempting to hide only in the
rendered version? You do know that lots of e-mail clients that are
configured to read in text-only mode may show a text version of your
HTML-formatted e-mail?

An HTML-formatted message *SHOULD* (but is not required to) contain both
a
plain-text MIME part and an HTML MIME part. For users of e-mail clients
that don't understand HTML or have been configured to read in plain-text
mode, they still have a plain-text MIME part that is readable and
displayed. Sending
HTML-formatted e-mails without a plain-text MIME part can raise the
threshold that the message gets tagged as spam and never delivered to
the recipient. A "good" HTML-formatted e-mail should look like in the
body of the message:

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C4F70D.B47E5430
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

<plain-text version of the message>

------=_NextPart_000_0001_01C4F70D.B47E5430
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<HTML version of the message>

So if you send an HTML-formatted e-mail without the plain-text MIME
part, expect to raise the chances your message gets detected as spam.
By not including a plain-text MIME part, some e-mail clients will then
use a converter to show the HTML part as plain text (sans tags) so they
may not see the portion you have enclosed within the <region></region>
tag pair, or they might see it if the converter doesn't handle that tag
pair or if the e-mail client doesn't provide a converter and just shows
all the HTML (which is, after all, just plain text even for the tags and
everything else in the message).

So they might not see your <region> part in an HTML-formatted message
but they can look at the source to see it. They might not see the
region part if their e-mail's HTML-to-text converter omits that part but
it is unlikely for quite awhile (until the HTML spec gets updated to
define such a tag). They might see the region part if there was no
plain-text MIME part (but then ALL recipients reading in plain-text mode
would not see the region part).

It won't work. Users still get to see ALL of the message when viewing
it in raw mode. Users have become quite used to looking at the source
code for the HTML due to phishing attempts using <A> tags that show one
URL as the text rendered in the HTML document but the real URL is
something else. If they export the HTML-formatted e-mail, its content
will just be all the text contained within the HTML-formatted e-mail,
and HTML is just plain-text, too, so they can see it that way.

Send different messages if you want the recipients to see different
messages. Or use a bulk e-mail program that will insert some content
based on one list of recipients and different content based on a
different list of recipients. I think even Word's Mail Merge could do
that. Once you send your message, you are no longer in control over
what the recipient sees in it or how they can use it. Users are getting
smarter because spammers and phishers are forcing them to get smarter.
Trying to hide content within the HTML coding of an e-mail won't hide it
from them looking at it.

--
_________________________________________________________________
Post your replies to the newsgroup. Share with others.
E-mail: vanguard_help AT yahoo.com (append "#NEWS#" to Subject)
_________________________________________________________________
 
V

Vanguard

SpiderBin said:
I'm not suggesting that it would hidden in HTML. It's obvious that
won't
work. An idea like Regions would have to be implemented within in the
Exchange Server.


Ah, a very critical point you left out in your blog (and the other one,
too). Unless Exchange is mentioned, it is rarely assumed (but
assumption is based on your present experience, so if everywhere you use
Outlook was also with use of Exchange then the assumption is different).
I'm not sure the target audience (other than the author of the blog)
would know Exchange was inferred in the setup.

However, I'm not sure embedding HTML-like tags would work. What might
work would be to define a special-type MIME part that could let Exchange
differentiate between different disposition=inline sections within the
body of the message. I'm no guru to MIME but I know that some MIME
parts described content that is not to be displayed although its
Content-Disposition is inline, like background sound. That MIME part is
inline but not displayed and so it gets handled differently by the
e-mail client.

Maybe defining a text/restricted MIME part would let Exchange know that
section would only be displayed for some recipients. I'm not sure MIME
headers could be used to specify which recipients to let see that part,
or whether an X-header would be needed to use in conjunction with the
special MIME part.

I did see in RFC 1341, page 2, Content-Type header, "A "message"
Content-Type value, for encapsulating a mail message." Hmm,
encapsulation sounds like it might be usable; a little more description
is on page 8. You would still need a means of denoting which recipients
can see the encapsulated message (actually who gets a version of the
e-mail that doesn't strip out the encapsulated message).
 
S

SpiderBin

My fault... I should have mentioned exchange too.

I was thinking perhaps xml based instructions to the server which would then
'decide and deliver'. From the client the original though was to have a rich
context menu letting the user drop in a region rule on any selected content.

SpiderBin
 
V

Vanguard

SpiderBin said:
My fault... I should have mentioned exchange too.

I was thinking perhaps xml based instructions to the server which
would then
'decide and deliver'. From the client the original though was to have
a rich
context menu letting the user drop in a region rule on any selected
content.


Actually I think this is a discussion best suited for the user community
focused on Exchange. This newsgroup is for the Outlook client. The
Exchange gurus might know if something you or I propose is something
doable within Exchange and won't have repercussions if a copy of the
message includes both Exchange and non-Exchange recipients.
 
Top