ietf-smtp
[Top] [All Lists]

RFC2821bis-02 Issue 30: Deprecate use of source routes completely and remove text

2007-04-23 16:37:03

Hi.

This has been discussed, but just to give it a number and insure
that it doesn't fall through the cracks...

2821 sort of danced around the issue of source routes, going a
little further than 1123 did in discouraging their use but not
getting rid of them entirely.  The method used to do this in
2821 is a little fuzzy, since it left the text in place
instructing relays to copy their own domains into the
backward-pointing address.  That was discussed as issue 26 and
the working draft for -03 now has that issue straightened out
(assuming I've gotten it right).

However, that discussion raised another possibility, which is
that now is the time to deprecate source routes entirely.  More
precisely that would:

        (i) Leave the syntax in place and continue to require
        that systems be able to accept and parse it.
        
        (ii) Forbid systems from using source routes, either
        changing the "they should be ignored but may be used"
        language that now appears in Section 3.3 (and more or
        less repeated in 3.6) to forbidding their use for
        routing or leaving those two sections alone (I consider
        eliminating the redundancy to be an editorial matter if
        I can figure out how to do it).
        
        (iii) Continue with (ii) by changing the "SHOULD not
        generate" in the second paragraph of 4.1.1.3 to MUST NOT.
        
        (iv) Get rid of Appendix C, replacing it with some
        handwaving to the effect that, if people really need to
        know how this obsolete feature worked, they should read
        821.
        
        (v) Strengthen the prohibitions in Appendix F.2.

So far, we've heard from a couple of people on-list who feel
that this is a much better idea than the patching contemplated
by issue 26 and no one who has argued for keeping them.  Whether
it is realistic to further deprecate them or not probably
depends on interoperability testing although we could arguably
prohibit the things as a bad idea that is not widely supported.

     john