Subject: Comments Re: 821bis, draft proto-09

From: John C Klensin <[email-masked]>
Date: Mon, 07 Dec 1998 06:37:07 -0500 (Eastern Standard Time)

On Tue, 01 Dec 1998 18:17:38 +0000 (GMT) Lee Thompson 
<[email-masked]> wrote:

> Section 3.3:
> 
> It is still very unclear if the <>'s in reverse-path are required and here's
> why:
> 
> >The first step in the procedure is the MAIL command.
> 
> >    MAIL <SP> FROM:<reverse-path> [ <SP> <mail-parameters> ] <CRLF>
> 
> You're using <>'s to denote special sequences such as spaces and CR/LFs.  In
> these cases the <>'s are omitted.   So going by this context, this line
> 'translates' as: "MAIL FROM:user@domain SIZE=4944\r\n".  This should be made
> more clear in the text.  (Section 6.1 and Appendix D have better examples of
> the MAIL FROM command, so perhaps even a 'see Section X.X.X for examples'
> would be helpful.)

I've patched this a bit, but the Syntax productions are, as
usual, authoritative.  In this, we have an unfortunate example
of exactly the opposite of what you suggest: examples tend to
not fully reflect text, and people tend to read examples (when
present) rather than text and draw their own inferences.  More
rigor, and fewer examples, is the usually-recommended solution.

  "MAIL FROM:<>" [ <SP> Mail-parameters ]
(end of section 4.1.1.2) and
     Reverse-path = Path
     Forward-path = Path
     Path = "<" [ A-d-l ":" ] Mailbox ">"
(in 4.1.2)

> 
> 
> The description for RCPT has the same issue.
> 
> 
> Implementation Note:
> 
> Many mail clients are not using the <'s and some include a <SP> after MAIL
> FROM:.  I believe while mail servers SHOULD use the recommended syntax, they
> should also allow the variants.    Speaking as a commercial developer,
> implementations that are 100% standard don't mean much if the customer's
> client software can't talk to the server properly.
> 
> 
> 
> Section 3.5.3:
> 
> I'd like to bring up the current practice of using VRFY to simply verify the
> syntax of an email address.  MANY CGI scripts are currently using this.   The
> problem with 'tightening' this up in SMTP server implementation is existing
> working conditions work; and a newer implementation will not.   I realize
> there is considerable interest in keeping standards tight; but the cat's
> already out of the bag.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _
> Lee Thompson                       [email-masked]
> Seattle Lab Inc.           http://www.seattlelab.com
> Product Manager