--On Monday, 23 April, 2007 00:20 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
John C Klensin wrote:
(2) Decide that source routes are ancient history and remove
Appendix C entirely, moving all discussion of source routes
into the present F.2, and shifting the rules for forward-
pointing source routes from "MAY ignore" (and use the Mailbox
information and MX records only) to "SHOULD ignore".
Good direction. My proposal was "outsource all cruft to a
separate document", but "put anything in F.2" is also fine.
And "put some bootstrap minimum in F.2 and then reference 821 or
2821" is pretty close to what I had in mind if we do that. In
some sense, the "reference" part is more or less equivalent to
your "outsource" idea, but without the pain of writing an extra
doc.
But don't remove the A-d-l syntax for paths, I think you want
"MUST NOT generate, MUST ignore", but still also "MUST accept"
for this cruft. Why only "SHOULD ignore" ? It can't work as
designed in RFC 821 if it's generally not generated. RFC 1123
even went so far to say that it never worked as designed... :-(
Well, I can't remember whether Craig Partridge or I wrote that
particular text (there are other possibilities, but we are the
most likely), but that probably wasn't the intent. The problem
--and sort of the last straw in the useful life of source
routes-- was that, if one had
<@a,@b,@c:x(_at_)d>
821 said that the message should be routed to host "a" but there
were some systems that got it backwards and tried to route to
"c" first and a few that, following the same practices that got
UUCP routes into trouble, would say "aha, I know who 'b' is and
have a better path to it than through 'a', so I'll just go there
directly". Combine those three variations with the requirement
that the reverse-path be constructed as an incremental set or
reverse source routings and, well, it would work as designed but
there was no way to predict just what would happen when a
message was sent.
Reintroducing source routes and requiring support for them
would, of course, constitute adding functionality
Folks would know where to find RFC 4408, in a certain sense it
reintroduces the lost reverse routes. RFC 4408 also claims
that source routes are "archaic", my appeal about this insult
was rejected... ;-)
<gag choke/>
The current working version of -03 incorporates a version of
option (1) above.
I'd like option (2) better. I could quote the "reverse path"
design as it was in 821 when necessary no matter which option
you pick in 2821bis - it's a philosophical thing about what
"responsibility" means for forwarders to third parties, and
what it means for MSAs accepting a MAIL FROM (4409 6.1). And
why the name "return-path" was NOT a stupid error that should
have been "bounces-to".
I did that text before concluding that it might be better to
just pull it all out. Let's see what others have to say -- I'm
certainly not attached to leaving it there.
john