Well wordsmithed. Why does it remind me of a EULA?
Mike
-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Dave
Crocker
Sent: Tuesday, March 11, 2008 11:06 AM
To: ietf-smtp(_at_)imc(_dot_)org
Subject: Re: email-arch -- Security Considerations
Dave Crocker wrote:
A question has been raised about the very brief Security
Considerations section in the email-arch draft. I've modified the
section slight, for the next draft, but the section still defers
meaningful discussion to existing specifications.
Having now received candidate text, and having now worked
vigorously to distort it beyond any hope of its having
benefit, here is what I propose for the Security
Considertations section:
<section title="Security Considerations">
<t>This document describes existing Internet Mail
architecture. It introduces no new new capabilities. The
security considerations of this deployed architecture are
already documented extensively in the technical specifications
referenced by this document. These specifications cover
classic security topics, such as authentication and privacy.
For example, email transfer protocols can use standardized
mechanisms for operation over authenticated and/or encrypted
links, and message content has similar protection standards
available. </t>
<t>The core of the Internet Mail architecture does not
impose any security requirements or functions on the
end-to-end or hop-by-hop components. For example, it does not
require participant authentication and does not attempt to
prevent data disclosure.</t>
<t>Particular message attributes might expose specific
security considerations. For example, the "blind carbon copy"
feature of the architecture invites disclosure concerns, as
discussed in section 7.2 of [RFC2821] and section 5 of
[RFC2822]. Transport of text or non-text content in this
architecture has security considerations that are discussed in
[RFC2822], [RFC2045], [RFC2046], and [RFC4288] as well as the
security considerations present in the IANA media types
registry for the respective types. </t>
<t>Agents that automatically respond to email have
significant security considerations, as discussed in
[RFC3834]. Gateway behaviors impact end-to-end security
services, as discussed in [RFC2480]. Security considerations
for boundary filters are discussed in [RFC3028].</t>
<t>See section 7.1 of [RFC2821] for a discussion of the
topic of origination validation. As mentioned in section
4.1.4, it is common practice for components of this
architecture to use the RFC0791.SourceAddr to make policy
decisions [RFC2505], although it is possible "spoof" this
address -- that is, to use it without authorization. SMTP and
Submission authentication [RFC2554], [RFC4409] provide more
secure alternatives.</t>
<t>The current document's discussion of trust
boundaries, ADMDs, actors, roles and responsibilities all
highlight the relevance and potential complexity of security
factors for operation of an Internet mail service. Internet
Mail's core design to encourage open and casual exchange of
message's has met with scaling challenges, as the population
of email participants has grown to include those with
problematic practices. For example, spam, as defined in
[RFC2505], is a consequence of this architecture. A number of
standards track or BCP documents on the subject have been
issued. [RFC2505], [ID-spamops],[RFC3685].</t>
</section>
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net