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.
Eric
Follow-Ups:
-
Re: Lyris
From: Mike Nolan <nolan@celery.tssi.com>
|
|
