Hi Stephen,
Stephen Kent wrote:
At 11:14 AM -0800 3/3/10, S Moonesamy 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. 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.
Right. ESMTP capability negotiation is a basic feature of ESMTP as
described in RFC 5321, this is not specific to 8BITMIME.
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.
RFC 5321 is also being revised by the YAM WG, so I would prefer any such
text to go there.
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?
Firstly, 8BITMIME is not suitable for transferring unencoded binary
data, it is only suitable for transfering 8bit text (e.g. textual
documents encoded in UTF-8). BINARYMIME (a separate SMTP extension) is
used to transfer unencoded binary data.
Secondly, the only thing that 8BITMIME changes is how certain email
messages or message attachments are transferred. So if there is a
malware that can take advantage of 8BITMIME, messages containing such
malware would take less bandwidth to transfer.
If so, that then that might also be a suitable comment to make in the
SC section.
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
