Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!dptg!att!chinet!ignatz
From: ignatz@chinet.chi.il.us (Dave Ihnat)
Newsgroups: comp.mail.elm
Subject: Re: Potential New ELM Feature
Summary: Certified & Registered Mail: A Good Idea, but Work...
Keywords: elm certified registered
Message-ID: <9752@chinet.chi.il.us>
Date: 5 Oct 89 19:25:17 GMT
References: <340@grc.UUCP> <144@limbo.Intuitive.Com>
Reply-To: ignatz@chinet.chi.il.us (Dave Ihnat)
Organization: Chinet - Public Access Unix
Lines: 60

In article <144@limbo.Intuitive.Com> taylor@limbo.Intuitive.Com (Dave Taylor) writes:
>
>This is an interesting issue that I've actually put a fair amount
>of thought into, for various companies...  with most Unix 
>configurations, Certified mail should be done at the transport 
>level (e.g. "sendmail"), and indeed currently is, if you include
>the header "Return-Receipt-To: <address>" in your message.

True.  However, if it isn't handled by your MTA, then it could be a function
of elm, in the same way that you can choose to have either elm or your MTA
attempt to resolve addresses now.  It would be, I'd think, a configurable
feature.

>Registered mail is a tougher one with the Elm paradigm of "don't
>touch the mailbox, just read it" because it then becomes tough
>to record that the user has read the message.  (that is, if I
>read a message from you, then eX)it Elm, should you receive TWO
>registered-mail-receipts?  One for the first time I read it, and
>one for the time I re-read the message after having exited Elm)
>
>The latter is a fairly complex issue, mostly due to the design 
>principle of Elm not actually modifying any of the mailboxes it
>looks at (where as Berkeley Mail, for example, adds a "Status:"
>header to each message so that the program can keep track of just
>this sort of thing...

Again, true.  I think that, if we DO want to keep "don't touch the
mailbox", then we're talking about a status file.  In this, you could
keep the status and identifying information concerning the mailbox and
mail items of interest such as certified and registered mail, high-priority
items, etc.  Once you've bitten the bullet and decided to keep this, you
could add other features, such as alarms for high-priority items that have
aged, etc.

>More interestingly, I think, is the issue of how one would keep
>track of whether receipts have been received for either of the
>two types of mail.  What about, for example, a special feature
>of the mail system that would keep a tally of all Certified and
>Registered email that you send, and would then automatically
>cross-reference and note when the receipts arrive?  Then you
>could have an easy mechanism to query "what messages haven't
>yet been received/read?" and so on.

Again, quite difficult, unless you include the status datafile.  Once you
have that, then much of this is easy to implement.

Aside from the work involved with the design and implementation, the only
other problem I'd worry about is synchronization of the status file with
the active mailbox or mailboxes; or rather, lack of synchronization due to
corruption, system crashes, or the modification of the mailbox(es) by other
mail display agents than elm.  This, of course, can be overcome--a
resynchronization and validation pass will almost certainly have to be done
by elm on startup--but it's probably going to noticably add to the startup
time, and we'll have to be sure that it's a robust recovery.  But I think the
benefits of this type of feature are worth it...

		Dave Ihnat
		Analysts International Corporation
		ignatz@homebru.chi.il.us (preferred return address)
		ignatz@chinet.chi.il.us