[Top] [All Lists]

Re: draft-klensin-rfc2821bis-00.txt structural and textual comments

2005-07-13 06:52:11

Thanks John for all your work.

Here a first hand reply to version -00

While I was reading the draft I started  thinking about the structure of the 
document, the current structure is complicated, has duplicates, and is not easy 
to follow  and maybe it is a good idea to rearrange the sequence of many 

At the end of this email i will put my suggestion of the sequence of sections.
Off course this is all open to discussion.
And i know it will give a lot of work.

Other suggestion:
2.3 Terminology: Splitting up of sections:

section 2.3  Terminology and subssections need to be split up so that every 
term has its own sub.sub.section.
This is mainly with the purpose that every term gets its own entry in the 

better a reference to RFC 2119

section 2.3.2 senders and receivers
Is it not better to replace senders with SMTP-clients and reiceivers with 

For clarity maybe it is even better to rewrite everywhere in the draft  client 
to SMTP-client and server to SMTP-server.

section 2.3.4
Hostnames are domainnames ???

section 2.3.9  Message Content and Mail Data, combine this with the (new -sub) 
section 2.3.1 Mail Objects

section 2.3.10 has a "fuzzy" reference
"the host specified in the domain part of the address."
in general the host is NOT the domain part so what is meant by the host 
specified in the domain part of the address??

Missing terminology:
return path a clear definition under terminology would be welcome.

section 3.6

section 3.6 also needs splitting up, the part about "undeliverable mail" 
notification message  (bounces) is better under section 6.1

The sentence:
SMTP servers are also permitted to ignore the route information and simply send 
to the final destination specified as the last element in the route and SHOULD 
do so.
should be rewritten as:
SMTP servers SHOULD ignore the route information and simply send to the final 
destination specified as the last element in the route

Textual typo's

page header line: should it not be ESMTP?

In the abstract there is a sentence
It consolidates, updates, and clarifies several previous documents, making all 
or parts of most of the obsolete.

subsections -> are missing

Structure changes:

my primary reson was that i wanted to get rid of section 4.3.1 and especially 
section 4,3,2 wich i found an eyesore
If you want to do this you need to integrate section 4.1 and 4.2
If you do this i realised hat section 2.2 fits under section 4.1.1

and so on and so on. It worked like a snowball...

my current suggestion is

Ps the numbers refer to the old section numbers:

1.   Introduction
1.1  Transport of electronic mail
1.2  History and context for this document
2.   The SMTP Model
2.1  Basic Structure
2.3  Terminology
2.3.1  Mail Objects
To be split up
2.3.2  Senders and Receivers
To be split up
2.3.3  Mail Agents and Message Stores
2.3.4  Host
2.3.5  Domain Names
2.3.6  Buffer and State Table
2.3.7  Lines
2.3.8  Originator, Delivery, Relay, and Gateway
To be split up
2.3.9  Message Content and Mail Data
can be put under 2.3.1
2.3.10   Mailbox and Address
2.3.11   Reply
New setion
return path

2.4  General Syntax Principles and Transaction Model
NEW section 2.4.1 8bit per byte transaction model

3.   The SMTP transactions: An overview
3.1  Session Initiation
3.2  Client Initiation
3.3  Mail Transactions

New section (3+ at the moment)
3+. SMTP Procedures: An Overview

3.4  Forwarding for Address Correction or Updating
(3.5 goes into section 4)
3.6  Relaying
3.7  Mail Gatewaying
3.7.1  Header Fields in Gatewaying
3.7.2  Received Lines in Gatewaying
3.7.3  Addresses in Gatewaying
3.7.4  Other Header Fields in Gatewaying
3.7.5  Envelopes in Gatewaying
3.8  Terminating Sessions and Connections
3.9  Mailing Lists and Aliases
3.9.1  Alias
3.9.2  List

4.   The SMTP Specifications
4.1  SMTP Commands  nd reply's general syntaxes
4.1.1  Command Semantics and Syntax
4.1.2  Command Argument Syntax
4.1.3  Address Literals
4.1.4  Order of Commands
2.2  The Extension Model
2.2.1  Background
2.2.2  Definition and Registration of Extensions
4.1.5  Private-use Commands
4.2.1  Reply Code Severities and Theory
4.2.2  Reply Codes by Function Groups
4.2.3  Reply Codes in Numeric Order
4.2.4  Reply Code 502  Extended HELLO (EHLO) or HELLO (HELO)  MAIL (MAIL)  RECIPIENT (RCPT)  DATA (DATA)
4.2.5  Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>  RESET (RSET)

3.5  Commands for Debugging Addresses
3.5.1  Overview
3.5.2  VRFY Normal Response
3.5.3  Meaning of VRFY or EXPN Success Response
3.5.4  Semantics and Applications of EXPN  VERIFY (VRFY)  EXPAND (EXPN)  HELP (HELP)  NOOP (NOOP)  QUIT (QUIT

4.2  SMTP Replies
not needed anymore

4.3  Sequencing of Commands and Replies
4.3.1  Sequencing Overview
not nescesary is already under 3.1-3.3

4.3.2  Command-Reply Sequences
directly at command in section ed

4.4  Trace Information
to be split up
4.4.1 received: header
4.4.2 return path

4.5  Additional Implementation Issues
4.5.1  Minimum Implementation
4.5.2  Transparency
4.5.3  Sizes and Timeouts
4.5.4  Retry Strategies
4.5.5  Messages with a null reverse-path
5.   Address Resolution and Mail Handling
6.   Problem Detection and Handling
6.1  Reliable Delivery and Replies by Email
split this section with a seperate section for
"undeliverable mail" notification message  (bounces)
6.2  Unwanted, unsolicited, and "attack" messages
6.3  Loop Detection
6.4  Compensating for Irregularities
7.   Security Considerations
7.1  Mail Security and Spoofing
7.2  "Blind" Copies
7.3  VRFY, EXPN, and Security
7.4  Information Disclosure in Announcements
7.5  Information Disclosure in Trace Fields
7.6  Information Disclosure in Message Forwarding
7.7  Resistance to Attacks
7.8  Scope of Operation of SMTP Servers
8.   IANA Considerations
9.   Acknowledgments
10.  References
10.1   Normative References
10.2   Informative References
Author's Address

collected ABNF is missing

An Index would be really welcome