Hi Stephen,
Thank you for your review.
At 04:08 03-03-10, Alexey Melnikov forwarded:
From: Stephen Kent <[email protected]>
Subject: [secdir] secdir review of draft-ietf-yam-rfc1652bis-03
[snip]
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.
This part of the effort is to move 8BITMIME to Full Standard. This
document does not change the 8BITMIME specification as defined in RFC
1652. There was a pre-evaluation and a Sec-dir review prior to this
document (
http://www.ietf.org/mail-archive/web/secdir/current/msg01064.html
). It would have been helpful if the YAM WG got a review of RFC 1652
at that time but that did not happen probably due to miscommunication
about the process. Please note that there hasn't been any reports of
security issues with this 16 year old specification.
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
I don't understand your concern in regards to the 8-bit data
transfer. If you mean that support for this SMTP extension could be
used to identify SMTP servers which do not support it, that is
correct. There is some text about 8-bit message content transmission
in Section 2.4 of RFC 5321.
This transport capability does not facilitate malware transmission as
email attachments can still be sent even if the SMTP client or server
does not support the 8BITMIME extension. It is only a matter of
using MIME for the 5322 message.
Could you please clarify the security issues you have in mind so that
I can bring them to the attention of the authors of this document?
Regards,
S. Moonesamy
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
