ietf-smtp
[Top] [All Lists]

Re: RFC2821bis-02 Issue 26: Source routes, especially reverse-paths

2007-04-22 15:33:32

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.

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... :-(
 
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... ;-)

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

Frank


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