[comp.binaries.ibm.pc.d] More comments on BACKMAIL

Kenyon_F_Karl@cup.portal.com (08/03/89)

                                 Kenyon F. Karl
                                  P.O. Box 451
                              N. Andover, MA 01845
        
                            Telephone: (508) 689-3147
                               Telex: 650-177-1813
                               MCI Mail: 177-1813
                       UUCP: Kenyon_F_Karl@cup.portal.com
        
                                  July 28,1989
        
        Alethic Software Inc:
        
        Dear Sirs:
        
             Following are a new batch of ideas for the further  develop-
        ment  of  the Backmail system (continued from my letter  of  July 
        15th):
        
             13.  It  is imperative that Backmail systems be written  for 
        as  many different kinds of personal computers as possible.  Thus 
        your objective should be to have a version of Backmail for  every 
        kind of personal computer in common use. 
        
             14.  Note  however  that  background operation  may  not  be 
        possible  for Apple II, Commodore and (other) CP/M based  systems 
        due  to  limited memory as well as the typical absence of a  hard 
        disk.  However this limitation should not be a major  problem  if 
        owners  of  these machines simply ran Backmail  as  a  foreground 
        application whenever the machine was not otherwise in use.
        
             15.  Minor  modifications should allow Backmail to  co-exist 
        with various Bulletin Board Systems (BBS). This effort is  impor-
        tant as the BBS is a prime means of distributing Backmail to your 
        potential  customers. Cooperating BBS systems would also be  able 
        to help with providing the 'second system' that potential custom-
        ers  need for testing purposes before adopting this  system.  The 
        modification  should be to return a simple ASCII message  to  the 
        caller (please wait, etc.) when a caller is identified as a  data 
        call  that does not follow the Backmail protocol. Backmail  would 
        then  kill itself and then transfer control to a BAT  file  which 
        would  load the BBS software needed to service the  call.  Tesing 
        should  start with BBS software systems that do not already  have 
        BBS  to  BBS E-mail capabilities (like FidoNet). Of  course,  the 
        final test would be to demonstrate compatability with FidoNet.
        
             16.  Backmail  should  also be adapted to  minicomputer  and 
        mainframe  operation  to serve as a 'home-office'  connection  to 
        various office automation systems and commercial E-mail services. 
        The  DEC 'All-in-1' system is a prime example of an 'OA'  system. 
        MCI Mail and Easylink are commercial E-mail services while Usenet 
        (UUCP) and Arpanet are non-commercial systems. Note that  address 
        translation  and message reformat services will be  necessary  to 
        interface  Backmail  with the internal format  of  the  mainframe 
        system. At this point, it might be useful to consider the various 






        modifications  needed to meet the X.400 standards for  electronic 
        mail services.
        
             17.  More thought should be given to the overall security of 
        the  Backmail system. Although we can trust the phone  system  to 
        ring the designated telephone on an outgoing call. However, until 
        ISDN services are available, the telephone system can not identi-
        fy  the source of a telephone call that is being  received.  Cur-
        rently,  the user of any Backmail system can very  easily  change 
        the phone number assigned to the system and thus cause the system 
        to  mis-represent  itself  as being another  system  for  various 
        fraudulent purposes.
        
             18.    A small improvement to improve security would  be  an 
        option to send a given message only on an outgoing call (as  well 
        as  several variations on this theme). This would insure  that  a 
        given message couldn't be diverted by a fraudulent inbound call.
        
             19.  A  major improvement would be to change the  'registra-
        tion scheme' so that a 'registered system' gets a customized copy 
        of the software by mail, with a new 'system identification' field 
        that shows the serial number, date and mail address to which this 
        particular customized copy was sent by mail. Unregistered systems 
        would  have  a  'system identification'  that  simply  identified 
        itself  as an 'unregistered system'. In any event,  this  'system 
        identification'  would be part of every message sent by the  sys-
        tem!  Of  course, there would still be a  'letterhead'  could  be 
        changed by the user as desired.
        
             20. I appreciate the effort that the developers of  Backmail 
        have  made  to  allow Backmail to share a  telephone  with  human 
        users.  However, the compromise that they suggest is 'uneasy'  at 
        best.  Thus for best results, users should be strongly  urged  to 
        install an unlisted telephone line for Backmail's exclusive use.
        
             21.  An  effort should be made to find  particular  combina-
        tions of modems and answering machines such that when an incoming 
        call  is  identified as being a voice call, then control  can  be 
        transferred to an answering machine to handle the call. This way, 
        Backmail  could share a phone line with an  'ordinary'  answering 
        machine  and thus both voice and data messages could be  received 
        on a 24-hour basis.
        
             22.  An  expensive solution to this problem would be to  use 
        the  'Watson' system for telephone answering  purposes.  Backmail 
        would  then need to pass control to Watson when voice  calls  are 
        received.