At 11:14 AM -0800 3/3/10, S Moonesamy wrote:
...
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.
OK
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.
First, this is a minor issue, so we ought not devote to much time to
it. I mentioned it because the tone of the security considerations
sentence is somewhat dismissive, suggesting that the authors did not
want to bother with this section :-). Nonetheless, it would be
preferable to explicitly note this side-effect of security
considerations section, since it is not called out in the 5321
security considerations and the text in 2.4 does not have a secruity
focus.
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.
Presumably you mean to say that binary attachments that are ideal for
delivering malware are supported irrespective of the use of this
feature, right? If so, that then that might also be a suitable
comment to make in the SC section.
Steve
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
