🚀 go-pugleaf

	From: Greg Skinner <gds@sri-spam.ARPA>
	Date: Wed, 19 Feb 86 00:07:48 PST
	Subject: loop control

	[ ... ] I think we should
	honor the Message-ID's generated at their source and refuse to
	process anything arriving with a Message-ID that has previously been
	processed.

For end-delivery duplicate deletion, that would work OK, except in the
presence of resenders (not forwarders) that add annotations.  However, for
loop detection and breaking, the stroke is too broad; some simple cases
break down.  Consider our case (RELAY.CS.NET, admittedly not your typical
host): we see a submission go by for header-people from one of our PhoneNet
sites with message-id 1234.foo@pudunk.edu.  You scheme would have us drop
the posting of that message to everybody behind relay.cs.net!  That doesn't
seem quite right, somehow.  With more local hosts being hidden behind mail
relays (when the MX namesolver implementations percolate out), this sort of
situation will be much more common than it is now.  It's already bad for
relay.cs.net, because we'll accept any mail message that we think we can
deliver, so some sites on the Internet use us as a staging host to get to
hard-to-reach sites.

The list exploder can't change the message-id, or direct recipients wouldn't
be able to filter out duplicates.

I'm all for loop control, but more information needs to be processed to
determine whether there's been a loop.  We use a very generous hop count,
and we would like something that would catch loops sooner.  Possibly a
repeated pattern or sequence of received postmarks would do it?
Unfortunately, that requires that at least two mailers in the loop insert
postmarks (if only one mailer does, it reduces to hop count, which is
probably a good last-ditch scheme) which *most* mailers do.  Of course, any
mailer trying to do loop detection should add its own postmark before
checking for a loop!  I don't think that simply checking for our own
postmark would work, either; consider a mail message being resent (as
opposed to forwarded) to multiple people or mailing lists by multiple
senders; all messages would have the original message-id.

What heuristics do *you* use when looking at a message to detect a loop? Can
you write code that executes in reasonable time (specifically, that you
would be willing to add to the incoming message processing) to implement
it?  This isn't the AI Digest, but...

Dennis Rockwell
CSNET Technical Staff