John C Klensin wrote:
Reviewing this issue briefly, there two connected questions
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.
Hi John,
If the concern is to use SMTP to help assist post processing mailbots,
then maybe we can approach some text added to 4.1.1.4 DATA (DATA) section.
MUA clients will not be sending a Return-path: (at least not with an
original message) in its DATA block.
So this is an issue mostly with routers whose feed come from receivers
who had prepended a Return-Path for the current hop.
One suggestion could be this:
During transmission, the client (MTA router) SHOULD remove
the current hop Return-Path: header line during the
DATA transfer.
or
During transmission, the client (MTA router) SHOULD
NOT transmit on the current hop return-path header
line during the DATA transfer.
That is why our router system does and I think it is BCP. I say that
because we evolved from UUCP/SLIP with the same concerns where "From "
was dealt with the same and similar way between hops. I recall the
design issues and also the researching and discussions about how other
systems did this.
In the end, each system can have their own internal method of storing
intermediate mail for routing and/or gating and it may or may not
include using Return-Path specifically to record a persistent entity for
the purpose of a return address. A good example is how we store our
intermediate mail in format like so:
ENV-FROM: address
ENV-TO: [internal userid or 0] address
ENV-TO: [internal userid or 0] address
ENV-TO: [internal userid or 0] address
ENV-TO: [internal userid or 0] address
...
ENV-DATA:
Return-Path:
Received:
And from this, our router will create XQT/CMD/DAT uucp style file format
files, one for each ENV-TO. The DAT now just has:
Return-Path:
Received:
and the persistent return-path is used by the router for the next SMTP
transaction MAIL FROM: command. At the DATA command, it is removed
(skipped) the first line and send the rest, making sure each header line
conforms the CRLF EOL.
But was it necessary to use Return-Path?
No. Not really. We could of used ENV-FROM, like I've seen others do
X-MAIL-FROM to store the return path during the intermediate routes.
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.
+1. I agree 100%. I think the system can only functionally work well
when it honors the z-order "LIFO" (last in/first out) nature and
methodology for network related header lines.
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.
My only comment is I think if its was added, developers might get the
erroneous idea that it is a required bounce format (DSN style) to follow
in order to send a bounce message.
If that is the goal, then IMO that is going to force a change for many
systems, including ours. It might be a welcome change, but a change
nonetheless.
Yes, I don't see any harm with referencing 3824 as a suggested bounce
format to convey the important information in a typical bounce message.
But not as a required format.