Date: 22 Oct 1997 20:48:00 +0200
From: kaih@khms.westfalen.de (Kai Henningsen)
To: drums@cs.utk.edu
Message-ID: <6gKdD40Hw-B@khms.westfalen.de>
In-Reply-To: <199710210009.UAA21817@spot.cs.utk.edu>
Subject: Re: "Reply-to as a replacement for From" considered hopeless
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Organization: Organisation? Me?! Are you kidding?
References: <199710210009.UAA21817@spot.cs.utk.edu>
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.

moore@cs.utk.edu (Keith Moore)  wrote on 20.10.97 in <199710210009.UAA21817@spot.cs.utk.edu>:

> > My understanding is, that drums should add no new functionalities, but
> > rather codify what already happens.
>
> No, that's not quite correct.  DRUMS cannot add new functionality, but
> neither is it required to codify existing practice.  To the contrary,
> DRUMS is supposed to fix existing practice where it is broken.
>
> Many people feel that Reply-To is broken for any case OTHER THAN
> "simple reply", and that DRUMS should fix this.

Well yes, _and_ that this can only be fixed with new functionality.


I think the following is nearly consensus:

* Reply-To: cannot solve all of the problems.

* Most of the problems occur because of mailing lists. Reply-To: is  
actually good enough (but not perfect) for mail that doesn't touch any  
mailing list.

* Mailing lists have more problems than just Reply-To:.

* Whatever we decide for Reply-To:, we should make certain that it won't  
be a problem for whoever tries to solve the mailing list problems. We  
certainly don't want a mailing list RFC that's in conflict with 822bis.


I feel that we have this problem because work in the area of mailing lists  
and mail base standards has been neglected for several years. However,  
this doesn't help us find a solution.


I think we (meaning the Internet) will need a standard track RFC for  
mailing list behaviour. However, I also think that we can only get there  
by way of an experimental RFC.

In any case, topics this RFC should address include how to identify mail  
distributed via a mailing list, how to identify submit and administrative  
addresses, how to manage subscriptions for the user side; how to  
distribute mail to a mailing list (wrt error handling, wrt which  
attributes to preserve and which not (Message Ids vs. DNRs), how to handle  
bounces, administrative requests, and so on for the list side. In any  
case, it ought to be compatible with what's currently  "Requirements for  
IETF Mailing Lists", 09/26/1997, <draft-moore-maillist-req-01.txt>.


All this should happen on an appropriate list, which drums probably isn't.  
ISTR that there was a list about mailing list headers; anyone have a  
reference?

MfG Kai