Comments on smtpupd-12

[Matti Aarnio <[e-mail]>]

I have tried to read the document as a complete newcomer without
understanding of how the protocol works -- mindset which has gotten
educated by seeing how various bigname vendors make mistakes at
their products...  (they *must* have newcomers coding the beasts.)



Part 2.4:

  This part speaks gives explicite strings in quotes for clarity,
  which notation is somewhat missed at some latter places when
  speaking of e.g. RFC 822 headers Date, From, ..  But more of that
  at appropriate place(s).  Explicite string notation is a good idea.


  Latter in this part says (last paragraph):

       "Metalanguage terms used in running text are surrounded by
        pointed brackets (e.g., <CRLF>) for clarity."

  Yet the same pointy brackets are used (or not used) at command
  samples.  This is somewhat confusing.



Part 3.3:

  The command syntaxes of  MAIL/RCPT/DATA  are different
  from  4.1.1.2/4.1.1.3/4.1.1.4 respectively.

  This will confuse people.

  My suggestion is to copy syntaxes from 4.1.1.* into here too.


  The second to last paragraph:

     When RFC 822 format is being used, the mail data include the memo
     header items such as Date, Subject, To, Cc, From [MSGFMT]. ...

  Here I would like to see explicte stringification of those header names
  with explicite double-colons:

     When RFC 822 format is being used, the mail data include the memo
     header items such as "Date:", "Subject:", "To:", "Cc:", "From:"
     [MSGFMT]. ...

  as in my thinking there is definite danger of readers confusing
  "MAIL FROM:<..>" and "RCPT TO:<..>" envelope commands at least
  to RFC 822 "From:" and "To:" headers.

  Ah, and the same with "Resert-To:", "Resent-From:", "Resent-Date:"
  headers.


Part 3.5.3:

  The first paragraph mentions twice reply code "220", which I seems
  to be a mistake and should be "250".

part 3.6.5:

  Add new paragraph to the end ?

     Usage of nationalized forms of "Re: " string in front of
     the reply message "Subject: content is observed causing
     awfull looking results in lenghty exchanges, especially
     when there are people using differently nationalized mail
     user agents:

        Subject: Re: Awt: Sv: Vs: topic text

     Therefore it is SUGGESTED that user agents sending email
     do always use standard international form when sending, and
     only do nationalizing of this prefix string at displaying
     (and possibly printing) the email.

Part 3.8.3:

  ">From the Internet ..."

  Possibly an artefact from email submission to draft repository ?

Part 4.1.1.1:

  This part does not carry discussion about the error procedure,
  parts 4.5 thru 4.7 of RFC 1869.

  Also a note about practical interoperability would be nice, e.g.:

     For practical interoperability, the SMTP server SHOULD ignore
     the parameter (or lack of one), and just assume it to be valid.
     Especially an attempt to verify that the expected domain parameter
     really is valid is a very quick way to trouble, as many ISPs supply
     their clients with premade email client configurations carrying some
     constant strings a'la: "HELO homepc".


Part 4.2:

  A reference to 4.2.1 which I suggest for splitting below.

Part 4.2.1:

  At RFC 821 annex E there seems to exist a notability problem of
  the multiline reply functionality.  Some software don't support
  receiving multiline replies, and this is propably because this
  important feature is not highlighted clearly enough -- with its
  own part number.

  I suggest that the last four paragraphs of this part are to be
  split into separate part - number as 4.2.2 with title:

    "Theory of multiline reply codes"



Part 4.4:

  This is a very long part, which actually carries three different
  topics.  I suggest splitting it to:

  4.4.1 The "Received:" header

  4.4.2 The "Return-Path:" header

  4.4.3 Treatment of accepted RCPT recipients with errors at DATA delivery time
	(this last feels to be somewhat misplaced)

  And moving relevant bits of the syntaxes to approriate parts, plus
  referring to RFC 822 header labels with quoted strings.

  Perhaps also adding there an introductory paragraph to begin 4.4.


  Similarly at "Received:" header generation I don't think it really is
  wise to generate:

     Received: from homepc (...) by ...

  but perhaps:

     Received: from reversed-ip-name-or-address-literal ([1.2.3.4]
	       "HELO homepc") by ...

  which neatly avoids users from hitting the system with oversize
  HELO string trying to overflow header generation buffsers, like
  is so much want of past obscuring attacks..

Part 5:

  I would begin this part with a short intro:

     Following applies to SMTP clients which do not have a-priori
     knowledge of which server to connect, and thus must use the
     DNS based email routing data.


  Now the first paragraph is algorithm description in free flowing
  text.  Could that be split into numbered paragraphs and/or bullets
  with possible introduction ?


part 7.2 (BCC)

  The first paragraph suggests that for security reasons sending
  SMTP systems might send messages separately for each recipient
  so that systems doing "for"-clauses (see also part 7.5) won't
  disclose all recipients.

  Perhaps at least adding a reference to 7.5 ?

part 7.4:

  Split to 2-3 paragraphs ?
  (in overall I find lengthy paragraphs of many sentences laborous
   to read, and I have this strange belief that such ones can always
   be split to separate paragraphs..)

part 7.5:

  Again split to several paragraps ?

part F.5:

  s/years MUST BE user/years MUST be used/   ??