On Fri, 10 Feb 1995 12:34:41 -0500 Marco Hernandez said:
>Hi all:
>
>In answer to some of the questions posted previously .. pardon the
>spelling errors )
>
>
>> 2) I assume that LISTPROC now supports BITEARN NODES, so that I as a
>> NAD can help with the users requests here.
>>
>
>No, we really want to move away from manually updated tables like
>bitearn nodes ... and move to more standardized forms of
>"automatically" deleting users by recognizing error message.  The
There is NO error message.  The user wants off the list and can't
for any number of reasons, and calls me to help.  Your "solution"
doesn't help my problem.
 
>error message situation on the Internet is dismal (IMHO).  Eric Thomas
>started an effort to stadardize error messages to make MLM's (Mailing
>List Managers) task of figuring out who/what/when to delete a user is
>the correct approach.
>
>
>> 3) If LISTPROC is using return-path:, it can handle source routes.
>> It is valid and proper.
>>
>
>It can handle source routing but I am unclear as to exactly what your
>question is ?  Source routes are legal ...  If you are referring to
>what Listproc uses for subscription addresses, It users the From:
>address not the Return-Path: or the envelope Mail address.  The freely
>available version of Listproc did this (although there is an option
>now to do the "correct" thing and use the From: address) and it was
>wrong !!!  CREN's Listproc does  what I feel is the right thing ...
I have two administrators at other sites running some other MLM
(I don't know the variety) who are insisting on using return-path:
at the subscription address, and then complaining that it is
a source route.  I was just asking if this is a listproc problem.
 
>
>> 4) LISTPROC updates the LISTSERV(tm) global database, so that users
>> here can continue to send requests to the local LISTSERV, and have
>> them forwarded to the proper system.
>>
>
>Listproc currently uses the Listserv global database to forward user
>requests to the proper site ...  Listproc will provide this service
>automagically in the next release (currently only the server at
>listproc.net does).   This ability is important to us.  It is a key
>feature  which users like.  Ideally It would be nice to develop a protocol
>for this that any MLM could use (Listserv, Majordomo, Listproc ...)
>I would be More than willing to work with other MLM developers on
>this.  Having a seamless web of information on mailing lists that
>users can access from any point is a winner for all concerned.
>Especially the end-users.
Unless this is there today, the proposal is not a solution.
 
>
>>6) Lists moving from LISTSERV(tm) to LISTPROC will not require
>>any changes by the subscribers, and all options and subscriptions
>>will be carried forward intact.
>
>You currently have to run the list subscribers/list configurations
>through a perl script.  It's fast and easy ...  If I remember
And often isn't done and causes all sorts of confusion for my
users.
 
>correctly (a qualified) all options are carried over.  There were some
>that listproc does not support becuase it did not seem relevant in a
>UNIX/IP environment ..  I would have to look back through my notes for
>that information if there is enough interest.
>
>> 7) LISTPROC now has a Distribute method of distribution to reduce
>> load.
>>
>
>Currently NO.  Two things on this ...
>
>1.   The large (VM / Listserv )sites that I have talked to
>        have been against having to do anyones mail but their own.
>        When asked if they would turn off such a feature they said "yes".
>        I did not do a scientific study .. no sample size calculations
>        etc...  Just in casual conversations with folks  that are using
>        Listproc, or evaluating it.
>
>        I fell that sites that run MLM's and lists have to do their
>        own SMTP.  That is not to say that the load can not be reduced.
>
>
>2.      The possiblity which is being explored is a DNS based solution
>        for mailing list deilivery centralization.
>
>
>        On our List machine here, we are currently seeing about a
>        35-40% difference between the number of tcp opens and actual
>        recipeints.  Some of that has to do with the fact
>        that you sometimes get 100 aol.com users on a list with 200
>        recipeints.  But as far as I have been able to determine
>        MX/CNAME DNS looksups account for about 15% of the total
>
>        That is hosta.ffo.bar and hostb.foo.bar ... are all resolved to
>        mailhub.foo.bar.  As such with some optimizing on the part of
>        your Mail Transfer Agent, you get one TCP open and one message
>        body sent to the site for all recipeints.
>
>        This is not ideal, much more can actually be done.
>        A new DNS record type, for the sake of discussion call it
>        MLX (Mailing List Exchanger), can be defined.  Unlike MX
>        records which are typically the end point for delivery, though not
>        allways, would be forwarders for low priority (or high) mailing list
>        mail.
>
>        Each entity (University,  Region, Business...)  Could define this
>        point dynamically.  Agreements could be set up to handle the mail
>        for a particular country, state, university via a central MLX.  with
>        the flexibility of DNS ... (i.e. splitting the load between multiple
>        host hosts by playing with TTL or changing the host).
>
>        The lookup could potentially be triggered via a
>
>                Priority: list
>
>        header which would then force it to be done prior to MX, CNAME A.
>        You could argue that it would be overloading the header, but
>        it appears easier than defining a new header type and the
>        Priority do not seem to be overused at this point.
>
>        A greater degree of consolidation of mail and efficiency at the
>        delivery point could be achieved.  In the end .... It is the receiving
>        institution / entity which bears the burden of fan out and
>        this fan out could be expanded N levels as well...
>
>        This is not short term but possible.  What it would involve is a
>        change in DNS implementations and MTA's.  But perhaps the
>        benifits are worth it.  (That is as long as we want to continue
>        to support Mailing Lists)
>
>>
>> BTW - There use to be a list on educom's listproc to discuss the
>> development of listproc.  This tickled my memory that I haven't
>> seen anything in a very long time, so I went ot check my subscription.
>> The list is "gone".  I must of missed the moving to a new address
>> posting, and gotten dropped off the list.  Could someone send
>> me the new address please.
>
>Yes, but never at edcuom ..  I think you are reffering to cren-list
>It was at cren.org but now it is at listproc.net ...
Was there an announcement?  Have these above design changes been
discussed there?
 
>
>It's been dead for a while .. the S/N ratio was also very high but I'm
>sure that can change....
S/N ratio is your opinion.
 
>
>That could also be a great space for these discussions :-)  Or I can
>provide a new space ...
>
>Cheers,
>
>Marco