HP3000-L Archives

November 1996, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Eric Thomas <[log in to unmask]>
Reply To:
Eric Thomas <[log in to unmask]>
Date:
Sat, 2 Nov 1996 14:39:59 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (40 lines)
To clarify the situation, I'd like to describe the steps that a MTA needs
to take in order to provide an incoming mail interface for LISTSERV:

1. Messages that are for LISTSERV need  to be identified. This is done by
   a combination of pattern  matching ("LISTSERV", "owner-*", "*-request"
   and  so  on)  and  lookup  (to  determine  which  mailboxes  are  list
   mailboxes). The preferred lookup method is to scan the directory where
   LISTSERV keeps it lists for names of lists that have been created. But
   if  that is  not  practical,  the information  can  be  loaded from  a
   configuration file. For instance, LSMTP and MX implement the preferred
   method, sendmail and PMDF use configuration lookup.

2. Execute  a number of  L-Soft provided routines to  create a file  in a
   predefined  format in  LISTSERV's  incoming spool  directory. This  is
   actually the simplest step, it's  all straightforward C code that just
   needs to  be able to  create files.  Interfacing these routines  to an
   existing MTA may  take time, but there is no  system specific issue to
   worry about. If you can create a binary file in C, you can do that.

3. Signal  LISTSERV that there  is new mail to  process. So far  this has
   never been an obstacle, but in a worst case scenario one could program
   LISTSERV to wake up every minute and look for new mail.

As far as L-Soft is concerned, the problem with MPE is that nobody in the
company  knows this  system and  at this  point we  don't think  that the
market is big enough to warrant hiring a MPE programmer, buying equipment
and  development tools,  etc. The  issue is  not really  whether we  will
ultimately  recover  our  investment,  but whether  the  return  on  this
investment will  be in the same  ballpark as the other  projects that are
competing  for   access  to  the   same  funds.  I  can't   really  blame
non-technical  types  for  feeling  safer  investing  in  (say)  NT-based
developments than in a system they have never heard of.

But, again, this doesn't mean we don't want to do this, or that we aren't
interested. It just means we can't do it ourselves, at least not alone.

  Eric

PS: I am not subscribed to HP3000-L.

ATOM RSS1 RSS2