Well wordsmithed. Why does it remind me of a EULA? Mike
>-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker >Sent: Tuesday, March 11, 2008 11:06 AM >To: [email protected] >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 > > >
