On Tue, 30 Oct 90 18:08:08 IST Zvika Bar-Deroma (Tel. +972 4 292706; FAX: +972 4 >This may sound trivial but I'll risk it: what is the benefit of PEERing >in the days of DIST2 ? I'm a bit confused and have my own ideas, but >would like to make sure I know what's going on. I would like to re-beat a dead horse here, after trying to explain this to someone else and ending up confusing myself again (know that feeling?). I'm sure someone can pipe in here and correct me if, well lets just say where, I'm wrong. Regular peered lists send people to the nearest peer. Peered lists are to optimize service to the subscriber. But distribution is another issue. Regular lists send out 1 file to each recipient, unless: * the target node has a mailer, then it sends out 1 copy for every 5 recipients, - but does it fold in sites with the same Mailer? or for clusters? DIST2 figures out who all is on the list, what backbone servers they are closest to, then routes a copy through the backbone to the appropriate servers to cover everyone on the list. Sort of like all backbones are peers. But that's where things go awry. To get single-recipient "To:" fields, these DIST2 lists send one copy per recipient (except it groups INTERBIT recipients into one BSMTP posting and replaces the RFC822 'To:' with 'Multiple recipients of list foobar'). There was talk some time ago about having DIST2 follow the multiple-recipient behavior of the original lists, but I don't recall anything coming out of it. DIST2 is much more efficient on the front end, transferring fewer copies over the long paths to the backbone servers; but then its near worst-case inefficient in the final split. Sure, it looks good only having yourself as the only recipient in the 'To:' field; but there is a price to be paid for it. Is there some way to have the DIST2 final delivery be done via the old way, ie, grouping multiple recipients? /Jeff/