Call For Papers
			       for the
			     Mar 23, 2002
		     Symposium: Redefining Email
	     The Harper Computing Security Research Group
	     		www.harpersecurity.com

Harper Security seeks presentations/papers from our members for the
March 23 meeting of the group.  There are no limits to the length or
format of the presentations.  White-board and LCD projector will be
provided, as well as a 1.5 megabit Internet connection.

The Topic:

   I was incensed last month by a New York Times article (soon to be
downloadable at http://www.harpersecurity.com/2002/mar) recommending
ways of making Email more manageable.

   To summarize the ideas of both those interviewed and the author:

    1. Automatically delete Email over 30 days old
        A. so that you don't have to deal with it.
	B. so it cannot be subpoenaed.
    2. Don't read long Emails.
    3. Don't read anything the you don't recognize.
    4. Keep Email to 3 lines.
    5. Delete ALL Email -- if it's important they'll call or Email again.
    6. Only read the first part of any Email.
    7. ...

   The above methods are of dubious worth (and ethics) and are
designed simply to minimize the impact of the torrent of Email.  As
assumptions of the people involved, you can list:

    1. An Email is a business or legal document.
    2. An Email is NOT a business or legal document.
    3. Buried in the huge mass of Email is a kernel of information not greater than the days before Email.
    4. Managing Email is impossible, so we need to TRIAGE it.
    5. Servers cannot handle the load of old Email.
    6. It's hard or impossible to find old Email.
    7. Old Email is a liability.
    8. ...

   What the article does is react to a BADLY BROKEN system and
attempt to fix it by changing the behavior of those using it.  I
suggest you do a Google search on Email Overload
(http://www.google.com/search?hl=en&q=Email+overload&btnG=Google+Search)
-- you will find that many people are having the same problem, and
using the same non-solution: "Change the User."

   We have the capacity to change both the tools and the UNDERLYING
SYSTEM.

   The current Email layer components:

    1. User Interface -- Elm, Outlook, Netscape
    2. File Structure -- If this layer is standardized it's a "From " delimited flat file
    3. Transport -- POP, IMAP and SMTP

   A possible replacement for this would be:

    1. User Interface
    2. DB API  (replacing POP/IMAP)
    3. DB / DB Server
    4. Document Signature Server/Identity Server
    5. CMTP (replacing SMTP)

   If we come up with good definitions of interfaces, we can leave the
actually implementation very loose and multiple implementations, all
compatible though different, could compete.

   We should aim to replace Email as we know it today, not fix the
current system.  There are political as well as practical reasons for
this.  A well designed, open system (if it doesn't accidentally step
on software patents) could provide businesses with a new killer app --
one which allows them to actually use the huge amount of information
being sent around, rather than be victimized by it.


This is not a small topic, and there's no certainty that we will get
very far in our discussions.

There is certainty that because of the selective nature of our small
group, we are all qualified to make real proposals, and that
everyone's ideas are worth hearing.

Please Email pom2@harpersecurity.com with topics/titles of
papers/presentations that you would like to cover.  Overlap will not
be discouraged, though I will be sending out lists periodically of
topics/presenters, so that you'll know what is being covered by whom.

In no way should what I've talked about above limit the scope of your
talk.  I don't pretend to know the whole answer, nor even the whole
question.

See you March 23rd.
RSVP



Paul Pomerleau
Co-founder, Harper Computing Security Research Group (aka Harper Security)
<pom2@harpersecurity.com>