🚀 go-pugleaf

pauln@nuustak.csir.co.za (Paul Nash) writes:
>However, if there is anyone who
>has a specially favourite mailer feature (apart from prescience), we would
>like to know about it, so that we can consider it.

  okay, i was thinking of posting a wish list at some point, but now
  you've poked me to do it.  sap has a home-grown mailer as well.  in
  general, it is slow and doesn't have the features i'm used to in mh
  (mh-e) and basically i hate the thing, but it does have some features that
  are very, very cool.  they are:

  o messages can have attributes.  these include: 
    o reply requested, where you can't delete the message until you've
      replied to it; 
    o express, where the message pops up to the top of
      the inbox stack and a window pops up notifying its arrival;
    o action, where the message, in addition to being read as a normal
      message, can also be a form with editable and non-editable fields
      (ie. in our bug-reporting system, a form is filled in with
      appropriate information and the target developer receives a mail
      message.  the mail message is transformed into a form where the
      priority, status, and notes can be updated.  one of the fields is
      the person currently responsible--this can be updated to pass the
      bug report on to another developer.)
  o message annotation. a copy of the message you send is saved and
    is annotated with when and when the recipient has read or performed
    an action on the message.

  that's a start.  i should find a copy of the manual and be a bit
  more specific.

Bill Wohler <wohler@sap-ag.de> <sapwdf!wohler>
Heidelberg Red Barons Ultimate Frisbee Team

Bill Wohler <wohler@sap-ag.de> wrote in <4071@sapwdf.UUCP>:

|     o reply requested, where you can't delete the message until you've
|       replied to it; 

Let's modify that: a letter with the reply-requested attribute should be
undeletable until you've either answered it or actively refused to answer it.

Maybe I should expand: responding to the letter would clear the attribute,
but you shouldn't HAVE to do that to delete the letter; you should be
prevented from unintentionally deleting it by having some positive action
required.  If you try to delete it without answering it, the mailer could
say "The sender requested a reply to this letter and you haven't sent one.
Delete anyway? n" with "no" as the default reply.  It shouldn't sit in your
mailbox forever if you don't want to answer it.

Otherwise the net will be flooded with "You demand a reply?  Here's your
blankety-blank reply: you send me one more blankety reply-requested message
and I'll make your postmaster sorrier than hell that you were ever allowed
access to mail, you blankety-blank!"

David W. Tamkin   Box 59297   Northtown Station, Illinois  60659-0297
dattier@ddsw1.mcs.com    CompuServe: 73720,1570    MCI Mail: 426-1818

In article <pauln.720877298@nuustak> paul@tantrum.csir.co.za writes:
>
>We are planning to develop a new, all-singing, all-dancing mail system.
>This will run over a mixture of IP and Novell networks, interactive and
>batched dial-up links,  It will integrate DOS and Unix workstations, as
>well as Windoze and OS/2, etc.  It will have gateways to SMTP, MHS, fax
>and anything else that we can think of (maybe even X.400).

>We have had a few discussions internally about the features that we would
>like, and have come up with a whole lot.  However, if there is anyone who
>has a specially favourite mailer feature (apart from prescience), we would
>like to know about it, so that we can consider it.

(1) Ability to attach arbitrary files.  Complete MIME functionality
should not be required on all platforms - just a minimal subset of text
or binary where binary types are not expected to be understood by other types
of machines.  It should be possible to detach the components of a MIME
message to individual files without having specific knowledge of the
content type built into the mailer.  The typical need is for people with
similar machines and software to be able to share platform-specific data
with the mail system being used as a simple transport mechanism.

(2) "Forms" functionality where a message can be sent out with a
specific format where the answers are forced into designated postions
when someone replies.  This is useful for machine-parsing answers.

(3) A clean split between the user agent and transport layers such
that any method of moving files between machines can be used.  This
means a well-documented file-level representation.  Something like
BSMTP with MIME attachments would be easy to integrate with existing
platforms, but something that mapped to X.400 body parts might work
too.   

(4) Transport layers should work for individual or site use and should
run over straight dial-up lines as well as network links or SLIP.  That
is, a transport should exist that would move a single user's mailbox
from a hub site (perhaps a unix host) to his local machine (perhaps
a notebook PC) on the order of dial-up POP.  A variation should allow
retreiving multiple mailboxes on the same call (perhaps from a machine
on a small PC network), and of course another variation would be used
when acting as a remote host (i.e. where the addressing notation directs
the mail to a different machine). Obviously uucp should be a possibility
for this, but perhaps not the only one.  The transport should be simple enough
that a DOS TSR is possible for scheduled background calls.  
 
Les Mikesell
  les@chinet.chi.il.us

paul@tantrum.csir.co.za

>Any replies in any form whatsoever will be appreciated.

	An expiration date that REALLY expires.  Something that
actually disappears when the date has passed.
-- 
He waits to hear her say 'forgive',
but she just drops her pearl-black eyes
and prays to hear him say 'I love you',
but he tells no more lies.

In article <BxtpM2.3tE@usenet.ucs.indiana.edu> erisande@silver.ucs.indiana.edu (Kryst the Philosopher) writes:
>
>>Any replies in any form whatsoever will be appreciated.

Something I haven't seen anyone mention yet is reliability with archive
and recall capability.  This can be important in commercial environments.
I'm running home-rolled version of an old message system that provides
this.  Although I've added gateways in and out to mailers I haven't
completely replaced it yet, largely because of this function.  The
sender supplies a sequence number in the header which once upon a time
had to be correct (starting from 1 each day) but now those are mostly
ignored and a "real" input sequence number is assigned as a message
is received.  As the message is delivered an output sequence is assigned
to it, and at the end of the day a message is generated showing how
many messages were received and delivered for each station so everyone
can tell if they miss or lose any (not too long ago most of the
stations sent directly to a printer).   There is a simple command to
recall any message by it's input or output station name, date, and
sequence number (input or output).   A few days of activity are always
on line for quick access, then we archive the input data and
the output logs needed and can still recall any message through
the system for the previous year or so.

Les Mikesell
  les@chinet.chi.il.us