John C Klensin <john-ietf(_at_)jck(_dot_)com> writes:
(1) Most of the functionality, for most cases, appears to be
addressed by
Reply-to: address1, address2, address3,...
Now, while that has rarely been well-implemented, it has been in
the standard since 822 or earlier. It is hard for me to see an
argument that a newer set of headers would work significantly
better.
I'm not sure Reply-To fully addresses the same issue that MFT/MRT and
NoReply address. Some of the problems with Reply-To in general are
mentioned in:
"Reply-To" Munging Considered Harmful
http://www.unicom.com/pw/reply-to-harmful.html
I'm aware that it primarily wanted to address only mailing list
software Reply-To munging.
(2) Your legacy discussion fails to discuss the interactions
among a Reply-to field that is present and these new fields if
they are also present. It seems to me that could get
complicated.
With my understanding of the proposal, I don't see this problem. The
neat thing with NoReply is that recipients aren't required to be aware
of the specification, existing conforming clients will do the right
thing. All processing happen on the submitter side. I only read the
proposal briefly, so I may be mistaken though.
See section 2.2.5 on what recipients should do. They aren't required
to do anything legacy clients don't already do, AFAICT.
(3) To the extent to which this and Reply-to overlap, it gives
us two different ways to do essentially the same thing. That is
rarely, if ever, a good idea.
I agree. Sadly, the functionality appear to be needed, given the
adoption of MFT/MRT.
(4) If these are sent out from a system that has no idea whether
the recipient will honor or ignore them, it seems to me that we
introduce the potential for huge levels of confusion and unmet
expectations. That isn't a showstopper, but argues against
this, IMO, unless it is really clear that there would be
significant benefits.
Again, as I understood it, this isn't a problem.
Regards,
Simon