RE: A Game (Email - Kelly)

>     Kelly> I know what IMAP is. I should have said "server based"=0D=0A> =
    Kelly> rather than "web based". The problem is that the client=0D=0A>  =
   Kelly> would have to send information to this IMAP extension.=0D=0A>=20=0D=
=0A> Most *nix-based clients have at least half a clue about this;=20=0D=0A=
> I would expect that Windows and Mac clients would be better=20=0D=0A> bec=
ause it's useful to the institutionalized *coff* er mobile=20=0D=0A> popula=
tion in large organizations.=0D=0A=0D=0AI'm quite certain that the *nix wor=
ld is way ahead of the Windows world=0D=0Ain this respect. The first thing =
is that Microsoft's email server=0D=0A(Exchange) does not follow any indust=
ry standard protocol, and is=0D=0Aessentially a closed system (although the=
y CLAIM you can=0D=0Aprogrammatically access it, good luck). Once an email =
goes into=0D=0AExchange, you might as well have flushed it down the toilet.=0D=
=0A=0D=0A>     Kelly> The other thing is that there are not spare CPU cycle=
s on=0D=0A>     Kelly> the server, while there are on the client.=0D=0A> =0D=
=0A> Do you assume the client workstations will have a fair amount=20=0D=0A=
> of disk, too=3F  If so, what I have in mind is a caching proxy,=20=0D=0A>=
 which speaks IMAP on both sides and provides the other=20=0D=0A> services.=
  The point of IMAP is that the users can access=20=0D=0A> their mail from =
any IMAP-capable client, but when they're "at=20=0D=0A> home base" they hav=
e your proxy services.  Although the=20=0D=0A> labeling feature is not as d=
iverse as WebDAV IIRC, it is=20=0D=0A> possible to set attributes on messag=
es.=0D=0A=0D=0AI do assume that client workstations have a fair amount of d=
isk space.=0D=0AThe IMAP caching idea is well worth looking at. I've always=
 been biased=0D=0Atowards POP3 because it's simple, but IMAP would provide =
some=0D=0Ainteresting possibilities here.=0D=0A=0D=0AIf I could create an I=
MAP caching server on the client that implemented=0D=0Amy filtering routine=
s, etc. then any client could look at the data...=0D=0Ahowever, without tho=
se MUA clients knowing about my IMAP extensions, you=0D=0Awould still have =
to use a custom client to get ALL of the benefit. I=0D=0Adon't think standa=
rd IMAP has much in the way of marking up emails...=0D=0AAlthough you could=
 do a passible job by adding custom headers to the=0D=0Aemails.=0D=0A=20=0D=
=0A> There may be better protocols than IMAP for what you want to=20=0D=0A>=
 do, but you can see now why I would start there, I hope.=0D=0A=0D=0AYes, i=
t makes a certain amount of sense.=0D=0A=20=0D=0A>     Kelly> How else woul=
d you determine the "role"=3F=0D=0A>=20=0D=0A> "Any way you want to." :-)  =
Send email to the filtering=20=0D=0A> proxy, for example. :-)  More sanely,=
 I believe there is an=20=0D=0A> extension protocol for IMAP.=0D=0A=0D=0AI =
think "filtering proxy" must be an unix thing. I've never heard of=0D=0Asuc=
h a thing for Windows email. I will look at the extension protocols=0D=0Afo=
r IMAP. You have put me on a new and useful path here.=0D=0A=0D=0AOne probl=
em remains though. All that email trapped in the Exchange=0D=0AServer... =0D=
=0A=0D=0A-Kelly=20=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AE-Mail messages may c=
ontain viruses, worms, or other malicious code. By reading the message and =
opening any attachments, the recipient accepts full responsibility for taki=
ng protective action against such code. Sender is not liable for any loss o=
r damage arising from this message.=0D=0A=0D=0AThe information in this e-ma=
il is confidential and may be legally privileged. It is intended solely for=
 the addressee(s). Access to this e-mail by anyone else is unauthorized.=0D=
=0A