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
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.
The IETF Notary WG has picked up the notion of standardizing
error notification (et. al.) and the Draft RFC is being re-worked
for what could potentially be the final time ??? There are
several implementations out ther (sendmail 8.6.9 and zmailer 2.9.x)
which attempt to work off the draft. The ability of having your MLM
be able to use standard error / delivery reports to make decisions
about subscribers is going to be possible and I hope that all the
implementors of MLM's will make use of it.
> 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 ...
> 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.
>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
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 ...
It's been dead for a while .. the S/N ratio was also very high but I'm
sure that can change....
That could also be a great space for these discussions :-) Or I can
provide a new space ...
Cheers,
Marco
|
