LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

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

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

Print Reply
Jeffrey R Kell <JEFF@UTCVM>
Tue, 18 Nov 86 16:31:14 EST
text/plain (44 lines)
A few comments:
 
(1) I had already discussed DISTRIBUTE for WISCVM with Matt Korn and Bill
    Rubin... we reviewed several options.  Most notable is that while the
    digests generally mail separately to each Bitnet user, these are at
    the same time generally sent as a single SMTP stream with multiple
    RCPT TO tags, and the copies are then forked at WISCVM.  If SMTPSERV
    simply cleaned up the RFC822 headers a bit, the bulk SMTP stream can
    then be sent to MAILER at CUNYVM, at least avoiding redundancy on the
    WISCVM-CUNYVM link.
 
(2) This continued on to splitting the SMTP into multiple streams, such
    as one for Europe, one for PSU-and-beyond, one for CUNY-and-above,
    and so forth.  This requires topological intelligence that SMTPSERV
    does not have.
 
(3) DISTRIBUTE was discussed; but again, the availability of servers, the
    alien DISTRIBUTE JCL, and other factors weighed against it.
 
In short, nothing was actually settled, although some testing was done
with the BSMTP packaging.  This, in turn, could not be carried out to any
great length since (a) not all Mailers were X1.23, (b) not all 1.23 Mailers
are defined as BSMTP 3 exits, and (c) Mailer 1.23 with BSMTP does not do
any clustering of deliveries except to common nodenames, and even then it
is questionable.
 
As to DISTRIBUTE and its ownership/management/etc issues, I can see where
end-nodes that 'happen' to be around hubs could get lots of traffic; but
if you are anywhere on the path the file would normally take (or you are
receiving a copy anyway) it shouldn't be an issue.  I personally prefer
DISTRIBUTE over the hassle of linking lists, defining peers, and testing
out the whole mess to eliminate loops (after various GET's and STORE's).
Ninety percent of the time a DISTRIBUTE would do a better job of sending
out list mail than a manually defined peer list anyway since it can use
other servers along the way.   But the *BEST* side effect is that using
DISTRIBUTE cannot cause a loop, since the recipient list is carried with
the data itself, and is always 'trimmed' along the way (it cannot 'grow'
back and loop).
 
I can see some concern, but lets not bury this valuable tool with paranoia.
Distribute could eliminate a *lot* more problems than it could ever cause.
 
/Jeff/

ATOM RSS1 RSS2