Reviewing this issue briefly, there two connected questions
First, whether the current language that indicated that old
Return-path headers MAY be removed in systems that have to
rebuild headers and construct new envelopes, that originating
systems should not send headers containing return-paths, that
ordinary relays must not tamper with headers to the extent of
determining whether return-paths are present, much less to
remove them, and that final delivery servers may, but are not
required to, remove earlier return paths.
Second whether a reference to RFC3834, "Recommendations for
Automatic Responses to Electronic Mail" should be added to
2821bis.
I have now reviewed these issues with Keith Moore, the author of
3834. We have concluded that the current restrictions are
about right: the only question is whether delivery servers,
which need to add a Return-path of their own should be required
(presumably with a SHOULD, possibly a MUST) to verify that there
are no Return-path header lines present, and removing them if
needed, before adding one. Requiring it would not match current
practice in several cases, but, if people are convinced that it
was necessary to ensure good interoperability, it could be done.
We are not convinced that it is necessary.
It is clear to us that RFC 3834, were it ever upgraded for
Draft, should get some additional text specifying that, if
multiple Return-paths are present, only the "top line" one
counts or, perhaps better, that only the "top line" one counts
whether or not there are others present.
Given the above, we don't see much value in a reference from
2821bis to 3834, although we don't see it as harmful either.
On reviewing the relevant text, I think the two paragraphs that
discuss this could probably be reworked a bit to make it more
clear that they do not contradict each other. I've added that
to my list of things to try to do for -04.
Just our opinions, although I would hope that they are somewhat
informed.
john