Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!brl-smoke!smoke!dennis@CSNET-SH.ARPA From: dennis@CSNET-SH.ARPA (Dennis Rockwell) Newsgroups: net.mail.headers Subject: Re: loop control Message-ID: <1152@brl-smoke.ARPA> Date: Thu, 20-Feb-86 00:56:52 EST Article-I.D.: brl-smok.1152 Posted: Thu Feb 20 00:56:52 1986 Date-Received: Sun, 23-Feb-86 05:57:09 EST Sender: news@brl-smoke.ARPA Lines: 47 From: Greg Skinner 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