Subject: [Emailcore] Ticket #17: proposed changes to remove source routes

From: Alexey Melnikov <[email-masked]>
Date: Wed, 24 Nov 2021 13:07:02 +0000

Hi all,

I've listened to the EMAILCORE session recording from IETF 112 and below 
is my best suggestion on how to resolve this ticket:

1) The last sentence of Section 2.1. (Basic Structure):

     Explicit "source" routing (see Section 5 and Appendix C and 
Appendix F.2) SHOULD NOT be used.

Suggestion: at the discretion of the editor: either delete the whole 
sentence (might not be needed in this section) or reword it to make it 
clear that thee feature is deprecated:

     Explicit "source" routing (see Appendix F.2) MUST NOT be used.

2) 5th paragraph of Section 3.3. (Mail Transactions):

     Historically, the <reverse-path> was permitted to contain more than
     just a mailbox; however, contemporary systems SHOULD NOT use source
     routing (see Appendix C).

Suggested replacement:

     Historically, the <reverse-path> was permitted to contain more than
     just a mailbox; however, source routing is now deprecated (see 
Appendix F.2).

3) 9th paragraph of Section 3.3. (Mail Transactions):

     The <forward-path> can contain more than just a mailbox.
     Historically, the <forward-path> was permitted to contain a source
     routing list of hosts and the destination mailbox; however,
     contemporary SMTP clients SHOULD NOT utilize source routes (see
     Appendix C).  Servers MUST be prepared to encounter a list of source
     routes in the forward-path, but they SHOULD ignore the routes or MAY
     decline to support the relaying they imply.  Similarly, servers MAY
     decline to accept mail that is destined for other hosts or systems.
     These restrictions make a server useless as a relay for clients that
     do not support full SMTP functionality.

Suggestion: either drop the beginning of this paragraph (up to this 
point) or replace it with something like this if the historic note is 
desirable:

     Historically, the <forward-path> was permitted to contain a source
     routing list of hosts and the destination mailbox; however,
     source routes (see Appendix F.2) are now deprecated.

The remainder of the paragraph probably need to be tweaked a bit:

     Consequently, restricted-
     capability clients MUST NOT assume that any SMTP server on the
     Internet can be used as their mail processing (relaying) site.  If a
     RCPT command appears without a previous MAIL command, the server MUST
     return a 503 "Bad sequence of commands" response.  The optional
     <rcpt-parameters> are associated with negotiated SMTP service
     extensions (see Section 2.2).

I would drop "Consequently" above, but the rest is probably Ok as is.

4) Section 3.6.1. (Source Routes and Relaying)

Suggestion to drop the whole section. It is not referenced anywhere else 
anyway.

5) 2nd and 3rd paragraphs of Section 4.1.1.3 (RECIPIENT (RCPT)):

     The forward-path normally consists of the required destination
     mailbox.  Sending systems SHOULD NOT generate the optional list of
     hosts known as a source route.  Receiving systems MUST recognize
     source route syntax but SHOULD strip off the source route
     specification and utilize the domain name associated with the mailbox
     as if the source route had not been provided.

     Similarly, relay hosts SHOULD strip or ignore source routes, and
     names MUST NOT be copied into the reverse-path.  When mail reaches
     its ultimate destination (the forward-path contains only a
     destination mailbox), the SMTP server inserts it into the destination
     mailbox in accordance with its host mail conventions.

Suggested replacement (single paragraph):

     The forward-path consists of the required destination
     mailbox.   When mail reaches
     its ultimate destination, the SMTP server inserts it into the 
destination
     mailbox in accordance with its host mail conventions.

6) Section 4.1.2.  Command Argument Syntax

2nd sentence of the 1st paragraph:
    Some of the productions given below are used only in conjunction with
    source routes as described in Appendix C.

Suggestion: remove.

     Path = "<" [ A-d-l ":" ] Mailbox ">"

Suggestion:

     Path = "<" Mailbox ">"

And finally:

    A-d-l          = At-domain *( "," At-domain )
                   ; Note that this form, the so-called "source
                   ; route", MUST BE accepted, SHOULD NOT be
                   ; generated, and SHOULD be ignored.

Suggestion: remove.

7) In Section 6.1.  Reliable Delivery and Replies by Email

Last sentence of the 2nd paragraph:

    If the address is an explicit source route, it MUST be stripped down to
    its final hop.

And the following paragraph:

    For example, suppose that an error notification must be sent for a
    message that arrived with:

       MAIL FROM:<@a,@b:user@d>

    The notification message MUST be sent using:

       RCPT TO:<user@d>

Suggestion: delete both, unless a reference to RFC 821 is desired here.

8) Appendix C.  Source Routes

Suggestion to delete the appendix. Appendix F.2 is a better place, 
because Appendix F is "Deprecated Features of RFC 821".

Some text from Appendix C cane be used for Appendix F.2 rewrite.

9) Appendix F.2 Source Routing

Replace text with a pointer to RFC 821.

Best Regards,

Alexey

---

From: Ned Freed <[email-masked]>
Date: Wed, 24 Nov 2021 06:42:34 -0800 (PST)

Comments inline.

>      Explicit "source" routing (see Appendix F.2) MUST NOT be used.

I think dropping the whole sentence is better. Less is more here.

>      just a mailbox; however, source routing is now deprecated (see

WFM.

>      source routes (see Appendix F.2) are now deprecated.

WFM.

> I would drop "Consequently" above, but the rest is probably Ok as is.

WFM.

> Suggestion to drop the whole section. It is not referenced anywhere else

Strongly agree.

>      mailbox in accordance with its host mail conventions.

WFM.

> Suggestion: remove.

All of this seems fine.

> Suggestion: delete both, unless a reference to RFC 821 is desired here.

WFM.

> because Appendix F is "Deprecated Features of RFC 821".

Dropping it is better, because this is really about how to use source
routes, and we don't need to talk about that.

> Replace text with a pointer to RFC 821.

I think keeping the first paragraph makes sense, but the second and third
definitely need to go.

				Ned

> --
> Emailcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emailcore

---

From: John C Klensin <[email-masked]>
Date: Sun, 28 Nov 2021 22:23:05 -0500

--On Wednesday, November 24, 2021 06:42 -0800 Ned Freed
<[email-masked]> wrote:

> Comments inline.
> 
>> Hi all,
> 
>> I've listened to the EMAILCORE session recording from IETF
>> 112 and below is my best suggestion on how to resolve this
>> ticket:
> 
>>      Explicit "source" routing (see Section 5 and Appendix
>>  C and Appendix F.2) SHOULD NOT be used.
> 
>> Suggestion: at the discretion of the editor: either delete
>> the whole sentence (might not be needed in this section) or
>> reword it to make it clear that thee feature is deprecated:
> 

Done.

>>      Historically, the <reverse-path> was permitted to
>>  contain more than     just a mailbox; however,
>>  contemporary systems SHOULD NOT use source     routing
>>  (see Appendix C).
> 
>> Suggested replacement:
> 
>>      Historically, the <reverse-path> was permitted to
>>  contain more than     just a mailbox; however, source
>>  routing is now deprecated (see Appendix F.2).
> 
> WFM.

Done.

>>      The <forward-path> can contain more than just a
>>  mailbox.     Historically, the <forward-path> was
>>  permitted to contain a source     routing list of hosts
>>  and the destination mailbox; however,     contemporary
>>  SMTP clients SHOULD NOT utilize source routes (see    
>>  Appendix C).  Servers MUST be prepared to encounter a list
>>  of source     routes in the forward-path, but they SHOULD
>>  ignore the routes or MAY     decline to support the
>>  relaying they imply.  Similarly, servers MAY     decline
>>  to accept mail that is destined for other hosts or systems.
>>      These restrictions make a server useless as a relay
>>  for clients that     do not support full SMTP
>>  functionality.
> 
>> Suggestion: either drop the beginning of this paragraph (up
>> to this point) or replace it with something like this if the
>> historic note is desirable:
> 
>>      Historically, the <forward-path> was permitted to
>>  contain a source     routing list of hosts and the
>>  destination mailbox; however,     source routes (see
>>  Appendix F.2) are now deprecated.
> 
> WFM.
> 
>>      capability clients MUST NOT assume that any SMTP
>>  server on the     Internet can be used as their mail
>>  processing (relaying) site.  If a     RCPT command
>>  appears without a previous MAIL command, the server MUST
>>      return a 503 "Bad sequence of commands" response. 
>>  The optional     <rcpt-parameters> are associated with
>>  negotiated SMTP service     extensions (see Section 2.2).
> 

Done.

>> Suggestion to drop the whole section. It is not referenced
>> anywhere else anyway.
> 
> Strongly agree.

Done

>>      The forward-path normally consists of the required
>>  destination     mailbox.  Sending systems SHOULD NOT
>>  generate the optional list of     hosts known as a source
>>  route.  Receiving systems MUST recognize     source
>>  route syntax but SHOULD strip off the source route    
>>  specification and utilize the domain name associated with
>>  the mailbox     as if the source route had not been
>>  provided.
> 
>>      Similarly, relay hosts SHOULD strip or ignore source
>>  routes, and     names MUST NOT be copied into the
>>  reverse-path.  When mail reaches     its ultimate
>>  destination (the forward-path contains only a    
>>  destination mailbox), the SMTP server inserts it into the
>>  destination     mailbox in accordance with its host mail
>>  conventions.
> 
>>      its ultimate destination, the SMTP server inserts it
>>  into the destination

I have put this in but have some issues with it.  See CREF after
that text.

>>     Some of the productions given below are used only in
>>  conjunction with    source routes as described in Appendix
>>  C.
> 
>> Suggestion: remove.
> 
>>                    ; Note that this form,
>>  the so-called "source                   ;
>>  route", MUST BE accepted, SHOULD NOT be
>>                    ; generated, and SHOULD
>>  be ignored.
> 
>> Suggestion: remove.
> 
> All of this seems fine.

Done.  We probably need to review whether Appendix F.2 (the
remaining discussion of source routing) needs the syntax we just
removed.
b
>>     If the address is an explicit source route, it MUST be
>>  stripped down to    its final hop.
> 
>>     For example, suppose that an error notification must be
>>  sent for a    message that arrived with:
> 
>>        MAIL FROM:<@a,@b:user@d>
> 

Done.  Again, we may need to do some rewriting on F.2, but
whatever we have to say should probably be there.

>> Suggestion to delete the appendix. Appendix F.2 is a better
>> place, because Appendix F is "Deprecated Features of RFC 821".
> 

Agreed and...

>> Some text from Appendix C cane be used for Appendix F.2

This is where I was headed above.  Appendix is going to need to
be rewriten.

> I think keeping the first paragraph makes sense, but the
> second and third definitely need to go.

I need to take a careful look at this before making a
recommendation.  Up to the chairs as to whether I do that before
posting -07, but it won't be within the next several days.  In
particular, while I don't think I've seen one of these turkeys
in the wild in this century and gather from the list discussion
that none of the rest of you have either, some of the text we
just took out makes suggestions about appropriate reply codes if
they are encountered -- suggestions that are, for obvious
reasons, not present in RFC 821.  So I'm a little reluctant to
throw information away, leaving the implementer with no guidance
at all other than that they are deprecated and, if one shows up
or a use case arises, they are are on their own with not even
suggestions to treat them as syntax errors.

best,
   john