Pete kindly replied, in part..
> Will every LISTSERV list-owner in the world have to reconfigure their
> list to stop  using the LISTSERV Distribute Backbone? Let's (put pressure
> to) solve the problem.

Yes, I want to solve this problem, but my eliminating the LISTSERV
distribute backbone from *my* LISTSERV distributions will provide better
service and better support of *my* clients, using less of my time.  I'm
convinced of it; I'd like the opportunity to try. I'm not smart enough to
know what other LISTSERV sites should do.

Here's why the LISTSERV distribute backbone sucks (for me):

1.  The store and forward nature of the backbone causes substantial
    delays from time to time.

2.  Finding the path a distribution, to any particular site, will take is
    difficult or impossible.

3. The backbone is a black hole.

    a. The LISTSERV console log doesn't show e-mail sent via the
        backbone. I can't verify from the console log that a post was
        distributed to a particular subscriber. For example, the message on
        the LISTSERV log might be "Mail forwarded to LISTSERV.CUNY.EDU for
        18 recipients.", whereas, I get specific messages for each
        distribution via SMTP, such as "Mail posted via SMTP to
        [log in to unmask]"

    b. I can't follow the path of a particular distribution to see how
        far it has traveled or where is is hung up or where or when it was
        delivered.

4.  When much mail was carried over BITNET, the LISTSERV distribute
    background was a performance and maybe a reliability enhancement. With
    almost all deliveries via SMTP now, the backbone is not needed (for my
    site's deliveries).

5.  If messages generated at my LISTSERV site are delivered by numerous
    systems, their delivery is somewhat or completely out of my control.
    Without the LISTSERV distribute backbone, these messages are delivered
    by *my* SMTPs, usually directly to each subscribers system.  Since the
    SMTP is mine, or my site's, I have substantial control over their
    operation.  I also have direct or nearly direct access to audit trails
    and current state information, so debugging any particular non or
    multiple delivery of posts is a relatively simple, and very *possible*
    procedure.

6.  It doesn't matter that a problem might be with a recipient's system,
    unless I can show that e-mail was delivered to them, and when.  I
    can't with the backbone; I can without it.

7.  Over the years, time and time again, subscribers and list owners have
    reported delivery problems to me, yet they and I can communicate via
    e-mail and LISTSERV can send them administrative e-mail.  These are
    instances of the backbone causing a problem where none would otherwise
    exist.

8.  I have one case where the backbone causes e-mail to go through an SMTP
    that has a bug that cannot be corrected soon.  Distributions through
    this (VM) SMTP fail randomly under certain conditions (e-mail greater
    than 64K bytes, with multiple concurrent SMTP deliveries). Allowing me
    to not use the LISTSERV backbone allows me to bypass this failing
    SMTP, allowing much better service to those (numerous) clients.

Yes, I'd like to solve the current problem, but hopefully this has shown
that teaching me how to eliminate the LISTSERV distribute backbone for
messages I generate is important to my site.

Perhaps I should just stop ranting here and give LSoft a call ...

Thanks and cheers, wayne

Wayne T. Smith                       mailto:[log in to unmask]
Systems Group - UNET                 University of Maine System
LISTSERV maintainer for http://lists.Maine.edu/