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