[Top] [All Lists]

Re: rfc2821bis-03 Issue 22: Return-path required removal

2007-04-27 02:49:30

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 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.


    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

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:


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.

<Prev in Thread] Current Thread [Next in Thread>