Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!brl-smoke!smoke!stef@uci-icsa.ARPA From: stef@uci-icsa.ARPA (Einar Stefferud) Newsgroups: net.mail.headers Subject: Re: Mail looping Message-ID: <1238@brl-smoke.ARPA> Date: Sun, 23-Feb-86 07:21:16 EST Article-I.D.: brl-smok.1238 Posted: Sun Feb 23 07:21:16 1986 Date-Received: Wed, 26-Feb-86 04:52:24 EST Sender: news@brl-smoke.ARPA Lines: 37 Long ago in a discussion group not too far away, we discussed one aspect of this "distribution" problem that I think is relevant in this current looping discussion. The original topic was failure return addresses, and hinged on the question of what is legit for a distributor to do to a message it is distributing to a list. Can it ethically and morally change the From: Sender: Reply-to: or Return-Path: fields to divert mail the might result from downstream events like failure, or reply, or whatever. Also, is it a violation of the sanctity of the seal for a LIST DISTRIBUTOR to look inside the header in the first place. As I recall the discussion, it was concluded that a LIST DISTRIBUTOR is in fact operating as a "USER AGENT" and not as a "MAIL TRANSFER AGENT" so it is fine for the list distributor to do anything its administrator wants it to do to the content of any distributed item. If there is any kind of contract between the administrator and the subscribers, it is that agreement that governs the administrator's actions. With this in mind, it seems simple enough to me for any LIST DISTRIBUTOR to put a special header field (like DIST-ID: ) which is can look for in any incoming item. If it sees such a thing it should shunt it aside for manual inspection, and this will prevent loops through that LIST DISTRIBUTOR, as long as no intervening transfer agants or user agents or LIST DISTRIBUTORS, et al, remove or change the magic in any DIST-ID: fields. This does not take care of other kinds of loops, but it would simply take care of LIST DISTRIBUTOR LOOPS. For those of you who are wondering what was decided about the earlier failure return question, we simply decided to have the list distributor insert a new "RETURN-PATH: list-request@host" field in place of the original RETURN-PATH field, without deciding what to do with the old one. ---- Stef