--- Begin Message ---

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 :.

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir

--- End Message ---

--- Begin Message ---

Hi Stephen,

Stephen Kent wrote:
 [...]

> 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.

Can you elaborate of your concern hear?
If you can suggest some text, that would be perfect.

> One might even cite the use of this transport capability as 
> facilitating malware transmission in e-mail attachments.

Does it?

--- End Message ---