Last Call Review of draft-ietf-yam-rfc1652bis-
review-ietf-yam-rfc1652bis-secdir-lc-kent-2010-03-03-00

Request Review of draft-ietf-yam-rfc1652bis
Requested rev. no specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-03-09
Requested 2010-02-20
Authors Dave Crocker, John Klensin, Marshall Rose, Ned Freed
Draft last updated 2010-03-03
Completed reviews Secdir Last Call review of -?? by Stephen Kent
Assignment Reviewer Stephen Kent
State Completed
Review review-ietf-yam-rfc1652bis-secdir-lc-kent-2010-03-03
Review completed: 2010-03-03

Review
review-ietf-yam-rfc1652bis-secdir-lc-kent-2010-03-03

Title: 

secdir review of
draft-ietf-yam-rfc1652bis-03




I reviewed this
document as part of the security directorate's ongoing effort to
review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.





This is a very, very brief document that is targeted to obsolete RFC
1652. It addresses transport of 8-bit (vs. ASCII) data via SMTP,
consistent with carriage of MIME 8BIT content encoding. This document
is part of the YAM effort, updating the series of Internet email
standards.





The security considerations section consists of only one sentence:
"This RFC does not discuss security issues and is not believed to
raise any security issues not already endemic in electronic mail and
present in fully conforming implementations of [RFC5321]." RFC 5321
(the updated SMTP spec) has an extensive security considerations
section, so this is a reasonable reference. I could imagine security
issues that might be associated with this document vs. 5321, since the
security section of the latter document does not address any security
concerns related to transfer of 8-bit data. For example, the handshake
used to determine whether an SMTP sever support receipt/relay of 8-bit
data might be used to target servers based on the lack of such
support. One might even cite the use of this transport capability as
facilitating malware transmission in e-mail attachments

 :

.