What to do about LOOPS

[Una Smith <una@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Dear Paleonauts (or PaleoNuts ;-),

It appears that there were two loops going on, the one from the
*.ca site since Friday afternoon (East Coast USA time) and another
from a *.com site that started late Friday night.  The occasional
loops are a consequence of two factors having to do with how the
PALEONET mailing list is configured.  First, headers of mail sent
from from PALEONET are configured with "Reply-To:" set to PALEONET
and "Sender:" set to PALEONET-OWNER.  Only "From:" is left alone,
with the author's e-mail address intact.  Depending on the precise
configuration of your e-mail software, this usually means that any
replies you send will go automatically to PALEONET.  This is often
helpful, and encourages public replies to PALEONET.  (Sometimes it
causes private e-mail to be misdirected to PALEONET.)

Depending on the precise configuration of several other programs
that perform mail-delivery tasks behind the scenes at your site,
these headers usually cause "bounce" reports or similar messages
about non-delivery to go to PALEONET-OWNER (Norm MacLeod or his
designated stand-in).  This happens all the time.  With as many
subscribers as PALEONET has, I would expect that Norm has to deal
with bounce reports from 5-20 flaky subscription addresses every
week.  This is normal.

Unfortunately, there are hundreds, if not thousands of slightly
different e-mail programs in use today, and the combinations of
them all must run to the tens of thousands.  They can all break
for any number of reasons, and they don't all work the same way
when they are working "correctly".  There are several "standards"
for the composition and interpretation of e-mail headers.  ("The
problem with standards is that there are so many of them.")  And
there is no one standard for mailing lists.  Hence, sometimes it
happens that the bounce report goes to PALEONET, not to Norm.

Because of how PALEONET is set up at present, any message sent
to it is sent to all subscribers, including the subscriber whose
local problem caused the first bounce.  Attempts to deliver the
bounce report naturally cause the generation of another bounce
report, which goes to PALEONET...  A LOOP is created, and it can
not be stopped without intervention from an administrator.

There is nothing we bystanders can do except (1) calmly delete
the messages, (2) temporarily unsubscribe, and (3) *perhaps*
send e-mail to the postmasters at both the subscriber's site and
NHM, drawing attention to the problem.

Re (3):  it's useful to ignore the first handful of bounces, to
give Norm MacLeod a chance to discover and break the loop.  It
does no good to send him e-mail;  he'll figure out what's wrong
without your help, as soon as he sees *his* e-mail stuffed with
bounce messages.  Also, if you didn't see the loop start, don't
bother sending e-mail;  you're probably already too late.  And 
don't be abusive or threatening;  that's rude, pointless newbie
behavior.

The risk of loops is one excellent reason to unsubscribe if you
are going to be away for a week or more.  If your own mailbox or
disk quota gets filled up with looping bounce messages, *your*
PALEONET subscription could be responsible for the next episode!

For the future, here are some possible ways of ameliorating the
problem (in any combination):

1.  PALEONET could preserve the original sender's address in the
headers, so that by default replies would go to the individual, not
PALEONET.  Pro:  reduces loops.  Con:  reduces discussion.

2.  PALEONET could refuse any articles sent from addresses not on
the subscription list (POSTMAST@foo and MAILER-DAEMON@foo are,
needless to say, not subscribers).  Pro:  reduces loops.  Con:
impedes legitimate submissions from non-subscribers, and impedes
posting by subscribers (like me) who do not or cannot always use
the same computer in a cluster of workstations.

3.  PALEONET could be administered via LISTSERV, arguably the best
mailing list manager (MLM) program available.  It used to be an
IBM mainframe package, but now comes in Unix flavors too.  Pro:
has powerful administrative features and the best loop-detection
and control of any mailing list manager that I know of.  Con:  may
be expensive.

Regards,

	Una Smith			una.smith@yale.edu

Department of Biology, Yale University, New Haven, CT  06520-8104  USA