Great Circle Associates List-Managers
(December 1996)

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Lyris
From: Eric Thomas <ERIC @ VM . SE . LSOFT . COM>
Date: Mon, 2 Dec 1996 20:12:52 +0100
To: Mark Galbraith <mgg @ sol . tins . net>, John Buckman <jbuckman @ shelby . com>
Cc: rogerk @ QueerNet . ORG, list-managers @ GreatCircle . COM
In-reply-to: Message of Mon, 2 Dec 1996 11:04:02 +7 from list-managers-owner @ GreatCircle . COM

On Mon, 2 Dec 1996 11:04:02 +7 John Buckman <jbuckman @
 shelby .
 com> said:

>If  every user  gets exactly  the same  message, the  task of  analyzing
>bounced messages is a difficult one, as you need to write a parser which
>is savvy to all the different mail systems out there, since there are so
>many different kinds of error messages.

Well, I don't think anyone on this forum ever claimed that writing a good
list manager was  an easy task. If  it were easy, there would  be no room
for commercial products :-)

>But,  in almost  all  cases, bounced  mail includes  the  header of  the
>bounced message in the error message.

Or rather, whatever the bouncing MTA  calls a "header". For many systems,
this is actually what is left of the header after converting to the local
proprietary  mail system.  This  may  not include  much  more than  date,
origin, recipient and subject.

>The advantage of  their technique is that it doesn't  have an efficiency
>penalty on general  list traffic, because it is  only used occasionally.
>The disadvantage is  that their technique requires  an intrusive "probe"
>message to be sent to every  subscriber. The advantage to L-Soft is that
>every  subscriber of  every list  using  this technique  gets a  message
>explaining how great L-Soft LISTSERV is.

The  advantage to  L-Soft is  that this  technique scales  up and  allows
customers to  keep running very  large lists  on PC systems  while taking
advantage  of the  new feature,  which increases  the number  of licenses
L-Soft can  hope to sell. It  also keeps resource usage  at the receiving
sites and bandwidth usage  where they are today. To give  you an idea, it
is estimated  that AOL receives some  1.5M messages a day  from LISTSERV.
Something tells  me that AOL  would not be  very happy if  these messages
were fed as 1.5M separate connections  with one RCPT TO: each, especially
if this  happened overnight following  the shipment  of a new  version of
LISTSERV and there was no way to back out. Upgrading mail servers in that
kind of  scenario could take days,  as new hardware might  be needed. I'm
only mentioning  AOL because it's  the largest online provider,  I expect
that the problem  would hold for any other large  provider (possibly even
more than AOL, which is very serious about keeping the mail servers up to
speed). It wouldn't be good for  L-Soft or for the mailing list community
in general if a  new version of the code crashed  a major online provider
just because resource impact at the receiving end had not been considered
in the design of a major new feature, or had been brushed off as "not our
problem". It would only lead  to managers decreasing mailing list budgets
(hardware and software) in favour of  usenet, web BBSes, etc. Call me old
fashioned, but  I feel  that Internet  vendors have  an obligation  to do
things "the  right way", even when  this is not the  optimal solution $$$
wise. To take an extreme case, a  very simple way to suppress all bounces
is to  send all  postings with  MAIL FROM:<>. With  enough hype  you will
actually  be able  to sell  this to  naive customers  as a  revolution in
mailing list management  and make money while  cutting development costs.
Meanwhile your  competitors will  be working hard  implementing solutions
that  actually solve  problems but  only look  more complicated  and thus
inferior to the users. Over time the lists will end up having hundreds or
thousands of  bad addresses that never  get cleaned up, which  leads to a
waste of bandwidth  and resource usage at both sending  and receiving end
and, guess what? It means more  license revenues as the mailing list host
gets slower and a second machine is bought to spread the load. The vendor
wins and the community loses.

Anyway, to  get back to the  matter at hand, L-Soft  recommends replacing
the  "message explaining  how great  L-Soft LISTSERV  is" with  a FAQ  or
similar  information.  See the  manuals  for  more details.  Finally,  in
version 1.8d  there will  be an  entirely new  probe mechanism  that will
further reduce the  resource impact of bounce-free  list management based
on the info we collected from 1.8c sites.

>Also,  our experience  is that  occasional probing  does not  work well,
>because it is susceptible to over-reacting to transient failures.

John, this  problem was discovered a  long time ago and  has already been
addressed in all  sorts of list management  packages, including LISTSERV.
I'm surprised  that you didn't  know that, given  the number of  lists on
which it has been discussed.


  • Re: Lyris
    From: Mike Nolan <nolan @ celery . tssi . com>
Indexed By Date Previous: Re: Lyris
From: Mike Nolan <nolan @ celery . tssi . com>
Next: Re: Lyris
From: Paul Graham <pjg @ urth . acsu . buffalo . edu>
Indexed By Thread Previous: Re: Lyris
From: Paul Graham <pjg @ urth . acsu . buffalo . edu>
Next: Re: Lyris
From: Mike Nolan <nolan @ celery . tssi . com>

Search Internet Search