Re: OPES and Email

On Thu July 7 2005 14:58, Tony Hansen wrote:
> 
> Heads up, email experts!
> 
> I don't know if you saw the recent I-D documents that came out, entitled
> OPES SMTP Use Cases (draft-ietf-opes-smtp-use-cases-02.txt).
[...]
> I'm co-chair of the OPES group, and am aware of its potential
> ramifications to the email world. So, I'd appreciate it if you could
> review the use-cases document. Discussion about the document is
> occurring on the [email protected] mailing list. (If you'd rather
> not join that list, I can channel your comments.)

I saw and downloaded it, but hadn't had time to review it.  I have now
skimmed over it; here are some initial comments not covering issues
raised by others (e.g. unchecked spelling errors), based on a cursory
scan of the draft:

1. Check against I-D checklist and I-D Guidelines (e.g. via idnits):
   there is no IANA Considerations section -- one is required per
   I-D Guidelines.  Has any thought been given to IANA considerations?
   [A debate has been raging on the IETF discussion list for close to
   a month, however the current IESG guidelines require an IANA
   Considerations section].

2. Numeric references are deprecated because they lead to RFC Editor
   busy-work (renumbering).  See the rfc-interest mailing list archive.
   They also make review and use unnecessarily difficult; I know what
   "[RFC2821]" references, but "[8]" isn't helpful.

3. Examples (some already noted by others) should be checked; a valid
   and carefully formulated example can illustrate a specification, but
   a poorly formulated or invalid example simply causes confusion.  A
   message or message fragment should be checked for validity -- there
   are validating parsers available for authors' use (see
   http://tools.ietf.org (tools inventory and wiki)).  The draft contains:
      From: [email protected]
      To: [email protected]
      Subject: Test
      Hi, this is a test!
   An empty line is required between the message header and the body text
   (see RFC 2822, which would be suitable as a reference...).  A valid
   message (RFC 2822 again) MUST have a Date field in the message header,
   and that is missing from the example.

4. Use of standard terminology aids clarity (RFC 1958).  FYI 18 provides
   some general terminology; FYI 36 for security.  RFC 2822 is also
   apropos for terminology.   In particular, note the standard meaning of
   "header" as defined in FYI 18 and RFC 2822.

5. Figure 2 implies that there is a direct connection between an MDA and
   MUA.  An MDA typically stores messages in a message store of some sort,
   which is accessed by an MUA using some protocol (typically one of
   direct file access, a POP version, or an IMAP version).  It is unclear
   from the draft whether or not there is any intention to address those
   other core mail protocols, whereas the draft does mention completely
   unrelated protocols such as HTTP -- that is at best rather odd.

6. Speaking of MUAs, the draft mentions filtering at MTAs, which is a
   dubious practice (as briefly touched upon by some other reviewers;
   basically it violates the end-to-end architectural principle (RFC 1958
   and others))).  Filtering may also take place from an MUA, which is
   well situated to consider filtering characteristics appropriate for a
   particular mailbox user (unlike some random MSA or MTA).  However, this
   use is not mentioned by the draft, which *seems* reasonable as a
   recipient MUA doesn't use SMTP, however as it is a primary means of
   filtering, it probably warrants a mention in the Introduction (oh dear,
   now I have to choose the order of segues).

7. Speaking of SMTP, some mention should probably be made regarding
   SMTP variants, viz. whether or not the draft is to be considered
   applicable to submission and/or LMTP.

8. Speaking of the Introduction, it would be nice to use general
   terminology until OPES-specific jargon is first defined.
   unfortunately, the Introduction starts with obscure jargon (e.g.
   "callout"), which coupled with the obtuse references (e.g. "[3]"),
   non-standard use of terminology, and lack of definitions of specific
   jargon in section 2, makes understanding the draft quite difficult.

9. Careful review of the text is warranted; how exactly can an error
   message cause removal of an attachment ("The attachment is removed
   by an error message")?

10. I know what OPES is, but what is "OEPS"?

11. Some consistency, particularly in the generality of approach, with
   existing practices documents would be nice.  In particular, draft
   sect. 4.9 is specific to one peculiar access mechanism, whereas e.g.
   RFC 1344 suggests a more general MIME mechanism.  Speaking of RFC
   1344, please pay particular attention to the implications of
   message/partial and message/external-body for filters (which act as
   a type of gateway) [much of the rest of 1344 has been superseded].
   In light of RFC 1344 and several years after 
   http://www.kb.cert.org/vuls/id/836088 a draft regarding the topic of
   content/virus scanners that doesn't address the security issues is
   bordering on unconscionable.

12. Speaking of security, the draft Security Considerations section
   needs some careful thought.  It is woefully inadequate (see above,
   BCP 72 and FYI 18).

13. The recommended organization (instructions2authors) is to place
   Appendices before References, and that implies that the references
   sections should be unnumbered.

14. Categorization of references needs to be carefully reviewed.
   Considering that the topic is SMTP and therefore requires some
   understanding of the details of that protocol (seems to be missing
   on the part of the authors, based on numerous errors in the
   examples, as noted by others), RFC 2821 should be normative rather
   than merely informative, for example.

15. Please don't encourage "Add a mark to the subject of the email";
   see RFC 4096.  That is a layering violation; Subject, To, From,
   Cc, Reply-To, Date, etc. are originator-specified fields (RFC 2822)
   and modification by others w/o the express permission of the
   author(s) is nothing less than forgery.  Modification of message
   content also invalidates security mechanisms such as digital
   signatures (RFC 1847).  Because of those considerations, such
   practices should be thoroughly and firmly prohibited rather than
   encouraged.

16. Examples of client-server dialogs use "S:" and "R:" labels, which
   would be fine if the draft were the only document using such dialog
   examples.  It is not, and the typical use would be "S:" for server
   and "C:" for client.  Unfortunately, the draft choice associates "S:"
   with the opposite part of the dialog from the typical cases, and that
   can lead to confusion.

17. Formatting could be improved dramatically; e.g. page 4 is mostly
   wasted empty space.

18. (general comment on subject matter)  Frankly, filtering can be
   accomplished in any number of ways; there are methods which have
   been in use in practice for quite some time (e.g. the simple and
   old method of passing information to a program and examining the
   exit code) and there is at least one Standards Track method
   specifically for email filtering (Sieve).  It is unclear precisely
   what benefit would justify the overhead of a heavy-weight (layers of
   new protocols) method such as seems to be the case for OPES (I haven't
   yet retrieved all of the numbered references for review, but that's
   the impression I get).   A method for filtering email that doesn't
   integrate with Sieve, and doesn't even mention it is simply mind-
   boggling.  See also item 6 above, and consider the possibility that
   this work might be abandoned.  I realize that authors don't like to
   hear that, but I think this work is going to be difficult to salvage
   considering the architectural and layering issues as well as lack
   of integration with existing mail-related standards track
   specifications.

19. What about internationalization considerations?  How can some
   random MTA in Omaha reasonably filter content being sent from a
   Croatian emigre to relatives in the old country, for example?

I think most of the other items that I noticed have already been
mentioned.  The document needs quite a bit of work, some requiring
careful thought (layering issues, protocol issues, security issues,
integration with Sieve and other mail-related Standards Track
specifications, relationship to the Internet Architecture and other
approved RFCs), some mostly mechanical (proofreading, spelling and
grammar checks, validation of examples, chacks against I-D/RFC 
guidelines, instructions, and checklists).  It's going to need at least
another version before it's ready for thorough review, unless of course
it is simply dropped in light of the architectural/layering/integration
issues noted above.