Re: Lyris

["John Buckman" <jbuckman @ shelby . com>]

> And anyway, why would your program generate 10,000 different messages
> for 10,000 subscribers?  Wouldn't it be more efficient to group
> deliveries of multiple addressees at the same location?  This would cut
> down on network traffic and workload on your system.

Yes, you are right that it is more efficient to send exactly the
same message to everyone on the list.  However, that technique
creates another problem, that of analyzing error mail.  

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.  You also need
to constantly update that error-analyzer, since error message
formats are constantly changing.  

As a list owner, it is fairly common to receive error mail which
bears almost no clues to which user bounced the message.  Or, the
clues are visible to a trained (human) list owner, but very
difficult for a program to recognize.

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

So, if you include a unique key in the header of each outgoing
message, which identifies each subscriber, that unique key will most
likely appear in the error mail as well.  This makes error
processing much easier, and (in our experience) more consistently
accurate, since you only have to look for that subscriber key to 
determine the bouncing subscriber.

The feedback we received when designing Lyris was that error mail is
a major problem when running mailing lists, and if there were a way
to effectively and automatically process error mail, it was worth
doing. Because there is an efficiency penalty with this technique,
we decided to write our own mailer to help make up for some of the
efficiency lost.

Now, you may disagree with us.  Perhaps it is your opinion that your
list server handles error mail just fine, and the efficiency
trade-off for improved error detection isn't worth it.  If that's
the case, Lyris isn't for you.

BTW, I believe L-Soft uses a similar technique, except that LISTSERV
sends a periodic "probe" message (which has L-Soft information about
their probe technique), with every probe message being unique, and
uses that to detect bad addresses.  

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.

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

Disclaimer: my only knowledge of L-Soft's "probe" technique is in
reading the probe message text that I've received as a member of
lists using L-Soft LISTSERV.  If I got my facts wrong, I'm not
trying to deceive, I just don't have access to the full information.

John

john@shelby.com, Shelby Group Ltd., http://www.shelby.com/