Re: email-arch -- Security Considerations

Dave Crocker wrote:
> Folks,
>
> 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.
> This is the latest version:
>
> > <section title="Security Considerations">
> >             <t>This document does not specify any new Internet Mail
> >                functionality. Consequently it is not intended to 
> > introduce any
> >                security considerations, beyond those already 
> > established for
> >                Internet Mail. </t>
> >             <t>However its discussion of the roles and 
> > responsibilities for
> >                different mail service modules, and the information 
> > they create,
> >                highlights the considerable degree to which security 
> > issues are
> >                present when implementing any component of the Internet 
> > Mail
> >                service. In addition, email transfer protocols can 
> > operate over
> >                authenticated and/or encrypted links, and message 
> > content or
> >                authorship can be authenticated and/or encrypted. </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. Details of security 
> > considerations for
> >                particular Internet Mail mechanisms are provided in the 
> > detailed
> >                specifications for those mechanisms.</t>
> >          </section>
>
> As for I8N, I believe that doing more in the document requires some 
> rather compelling consensus among the community -- ie, you folk.
> To the extent that anyone insists the document say more than the above, 
> please consider that requirement to generate candidate text as resting 
> on your own shoulders...
> Again, it's not that my own view is unfriendly to having the document 
> say more, its that I am very concerned about derailing the document with 
> an effort that is clearly difficult to do thoroughly and well, and get 
> agreement from the community.
> d/
Shrug.

It is the mindset thats helped mold and perpetuate security issues we 
have for the past 20 years, and it is same "deferment" attitude that 
will continue or even create new security issues for the next 20. But 
who cares right?  We will probably be dead and bury by then.
Sorry, you asked and I'm from the "Getting it right the first time!" 
engineering quality school of thought.
You see, the thing is, you are going to do what you want anyway. So if 
you are looking for any pat on the backs for ignoring security concerns, 
like in the DKIM/SSP project, I just wish to express that even thought 
one may not able to change your mind, there are those who don't always 
agree with your position being taken for these important areas that will 
have an affect on others.
--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com