[Top] [All Lists]

[ietf-smtp] Items for rfc5321bis

2019-12-29 17:41:27
To get these into the discussion mix:

1. RFC 5598 // Add a citation to this, which is am IETF-stream consensus description of email architecture and terminology. Remove language that conflicts with that document.

2. RFC 6409 // Add a citation and text that clarifies SMTP is for MTA interactions and not those involving MUAs.

3. Section 3.7 Mail Gatewaying // Delete

This topic is not relevant to SMTP. It is relevant for processes at a higher level in the architecture and belongs in a separate discussion. The normative language here is actually counter-productive. Moving this text to a separate discussion will permit it to be reviewed and modified to represent modern operational realities.

4. Section 3.9. Mailing Lists and Aliases // Delete

Basically, this section is archaic. In reality, neither of these topics pertains to the mechanism for moving email from an Internet originating MTA to an Internet delivering MTA, which is what SMTP does. These are issues at a higher level in email architecture. The section's presence in the protocol doc is counter-productive.

5. Section Verify (vrfy) // Consider deleting

My impression is that abuse behavior has rendered this command dangerous in SMTP.

6. Section Expand (EXPN) // Delete

My impression is that it has been decades since this command was reasonable for use on the Internet in SMTP.

7. Section F.1 TURN // Delete normative clause.

The word 'deprecate' has a definitive semantic. The clause at the end saying 'should not' conflicts with that semantic.

Whether this section should cite RFC 1985 and RFC 2645 is a separate question.

8. Review every normative assertion, for reasonableness in the face of modern operational challenges. I suspect some should be changed.

Dave Crocker
Brandenburg InternetWorking

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [ietf-smtp] Items for rfc5321bis, Dave Crocker <=