Re: Understanding response protocols

Bruce Lilly <blilly@erols.com> Thu, 23 September 2004 00:42 UTC

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N0gw7q004078; Wed, 22 Sep 2004 17:42:58 -0700 (PDT) (envelope-from owner-ietf-822@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8N0gwEN004076; Wed, 22 Sep 2004 17:42:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-822@mail.imc.org using -f
Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N0gvbC004064 for <ietf-822@imc.org>; Wed, 22 Sep 2004 17:42:58 -0700 (PDT) (envelope-from blilly@erols.com)
X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication
X-Trace: 6bQYKzCKPjfUHlInLk1IM07RXrw/HbysJypmUWndUOE=
Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1CAHhP-0002LQ-00; Wed, 22 Sep 2004 20:43:03 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i8N0Lhso006938(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Wed, 22 Sep 2004 20:21:44 -0400
Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i8N0LgLr006937(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Wed, 22 Sep 2004 20:21:42 -0400
Message-ID: <41521714.7090202@erols.com>
Date: Wed, 22 Sep 2004 20:21:40 -0400
From: Bruce Lilly <blilly@erols.com>
Reply-To: ietf-822@imc.org
Organization: Bruce Lilly
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
X-Accept-Language: en-us
MIME-Version: 1.0
To: Charles Lindsey <chl@clerew.man.ac.uk>
CC: ietf-822@imc.org
Subject: Re: Understanding response protocols
References: <8DCC7220-FB84-11D8-B65D-000393DB5366@cs.utk.edu> <41350CB4.2000903@erols.com> <20040906102210.GA1974@apb-laptoy.apb.alt.za> <73ED6CED-0144-11D9-AA76-000A9571873E@guppylake.com> <20040908190020.90234.qmail@cr.yp.to> <Pine.SOC.4.61.0409090913310.18976@draco.cus.cam.ac.uk> <41406FE8.5000303@erols.com> <Pine.SOC.4.61.0409091700470.18976@draco.cus.cam.ac.uk> <20040909223059.99752.qmail@cr.yp.to> <41437112.8030807@erols.com> <20040912033326.52735.qmail@cr.yp.to> <41471F70.9090602@erols.com> <I436Bx.4sq@clerew.man.ac.uk> <414B8EDD.3090605@erols.com> <I4C4LL.AKo@clerew.man.ac.uk>
In-Reply-To: <I4C4LL.AKo@clerew.man.ac.uk>
X-Enigmail-Version: 0.86.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-822@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-822/mail-archive/>
List-ID: <ietf-822.imc.org>
List-Unsubscribe: <mailto:ietf-822-request@imc.org?body=unsubscribe>

Charles Lindsey wrote:
> In <414B8EDD.3090605@erols.com> Bruce Lilly <blilly@erols.com> writes:
> 
> 
>>Charles Lindsey wrote:
> 
> 
>>>It is quite clear to me that _any_solution to the problems we are
>>>dicussing will require changes to MUAs before it becomes effective. MFT is
>>>a nice solution on the face of it, but requires the most change to
>>>existing MUAs.
> 
> 
>>And MTAs.
> 
> 
> Why MTAs? MSAs perhaps.

Some MTAs rewrite addresses. For example, a border MTA may rewrite
foo@bar.baz.com as foo@baz.com in order to hide internal host names.
If such addresses are rewritten in the envelope and in standard
address fields, then any new address field that is intended to be
used by recipients should be similarly processed.

>>>Mail-Copies-To would he easier to introduce, but it does
>>>not do such a good job.
> 
> 
>>Not easier -- it has the same problems and requires MUA and MTA
>>changes.
> 
> 
> What MTA support?

See above.

>>>Looks like we have to choose some least-harmful
>>>alternative. Reply-To is what we have at the moment, and it is clearly not
>>>working.
> 
> 
>>It works fine for me...
> 
> 
> But not for anybody else, apparently.

It seems to work fine for others that use it also.

>>>It is well enough defined for us to understand what it would entail.
> 
> 
>>Where's the ABNF? Where's the definition of how the field is handled
>>w.r.t. message fragmentation and reassembly?  Where's the discussion
>>w.r.t. interaction with Reply-To in RFC 2822?  Where's the discussion
>>about automatic responses in RFC 3834?
> 
> 
> We are discussing a suggestion that it might be introduced as a solution
> to the problem. You do not need ABNF and a full draft (though they would
> be required eventually). But, if you insist, that you may consult
> ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-drums-mail-followup-to-00b.txt.
> Oddly, that draft does not actually specify any ABNF, but you may assume
> it intended syntax similar to the Reply-To field in RFC 2822.

Actually there is a syntax specification (however it omits the
colon which delimits field name from field body...).  You also
seem to be very confused about address fields; you claim that
the syntax in Jacob's 5-year-old draft is intended to be like
that of the Reply-To field, but Jacob's draft specifies a
mailbox-list whereas Reply-To uses an address list.  That
draft would make wide responses difficult at best, since it
deprecates such wide responses.  There are provisions that are
impractical for implementation.