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 ietf-openproxy(_at_)imc(_dot_)org 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: steve(_at_)example(_dot_)org
To: sandra(_at_)example(_dot_)com
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.