--On Saturday, 01 August, 2009 12:46 +0200 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:
...
Frank Ellermann noted the added phrase, and commented about it
on April 26, 2007
That's a point where you could mention that this used to be
no
key difference under RFC 821, because "in any case, the SMTP"
added "its own identifier to the reverse path". There might
be
better places to explain that RFC 1123 broke the original
SMTP
design in its quest to get rid of the source routes.
That was the concern of the discussion, rather about concepts
than wording. In facts, Frank used to note discrepant usages
of terms (e.g. "return path" vs "reverse path", in the same
message) but missed also this spurious "backward-pointing
address". (Currently, there are exactly three occurrences of
the word "backward" in RFC 5321.) I found no other thread
mentioning that phrase. John replied
Send text, but my inclination is to not change this further,
especially to reflect the long-dead "copy own address into
reverse-path stuff".
That's it, almost. Frank had dropped that point in his further
reply. I jumped on that list months later, after Frank's
suggestion. I independently noted that phrase and had tried to
leverage on its inconsistency for introducing a conceptual
change which had been rejected.
Alessandro,
It is precisely the interconnection between this tiny change and
"the 1123 decision was a mistake" (something that DRUMS declined
to open and that no one has gotten traction for opening since)
and the terminology about rerouting email at various levels that
makes me unwilling to treat changes in this area as anything but
substantive and needing WG review. That would be the case even
if I had reviewed the text in question (which I have not) and
agreed with you.
For those who haven't been following this closely, the 1123
issues was the change that turned Return-path in RCPT from
<@relay3,@relay2,@relay1:local-part(_at_)domain>
to
<local-part(_at_)domain>
regardless of the path taken. My guess is that some of us would
argue that the change was absolutely correct, others would argue
that it is much too late to reconsider whether it was the right
decision at the time or not, and still others would argue that,
in this world of hostile or unwanted messages with faked
headers, the decision should be revisited and changed. I've
fairly sure that split would make it very hard to get enough
consensus to make a change but I, at least, would not oppose
revisiting it if we could do so in a highly-focused way.
But I'm simply not going to make _any_ change in this area
unless the WG has discussed it and the Chairs have told me what
to do.
One of my tasks for the last several days is to assemble a
template for the revision of 5321. That template is basically
the starting point for the notification/request to IESG (for
convenience, I just posted the most recent version into the WG
Wiki (http://trac.tools.ietf.org/wg/yam/trac/wiki)
I will include, in some form, a statement to the effect that we
will review terminology changes made between RFCs 821 and 2821
and between 2821 and 5321 where appropriate to determine whether
the WG is still happy with them and that some small changes are
possible on that basis. Assuming the WG and IESG agree with
that characterization, that should eliminate the procedural
issue, permit us to concentrate on the substance and, as SM
suggests, hold a discussion in the context of the forthcoming
draft.
john