Who is trying the rhetorical judo on whom? NOMAIL is out of scope, wildcards for signature policy are not.
There are two deployment stories we need to be able to give, one that meets 95% of needs with legacy infrastructure support, the second that meets 100% of needs with a minor incremental change to the legacy infrastructure. The second of these provides a slot ready made for NOMAIL, (and for STARTTLE, PGP and SMIME if you like). I am meeting your set of requirements in full. I am just not doing so in such a way that my proposal is out of scope, that is all. > -----Original Message----- > From: Hector Santos [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 05, 2007 3:23 PM > To: Hallam-Baker, Phillip > Cc: Michael Thomas; Scott Kitterman; [email protected] > Subject: Re: [ietf-dkim] RE: I think we can punt the hard > stuff as out of scope. > > Hallam-Baker, Phillip wrote: > > > In many parts of the world there are folk throwing rocks at > each other > > or worse because they can't settle their differences. Why > should that be > a concern? > > Spare me the rhetorical judo. > > I think the PROMISING SSP and rather simple protocol has been > hijacked with academic hogwash and now we got a rabid dog > loose in the market running unprotected. > > We need to get this solved pronto or risk DKIM-based becoming > another DOMAINKEYS junk/bandwidth inducing generator systems > - IGNORED. > > You have not been very clear in your proposals or comments > towards others, atleast not to me. To me, you exhibited > MIXED directions. > > We have had lots of ideas here and many were well established > feature list since day one and for the life in me, I don't > quite understand why we are trying to CURE cancer when we can't! > > In DSAP, I spelled it out very clear regarding some very > fundamental security issues. > > When a EMAIL comes in with a purported DKIM signature, there > is a new level of security expectations with that > transaction. It is no longer an OLD LEGACY transaction. The > concept is akin to a client specifically using PORT 587 - > when it does, there is a NEW LEVEL of LEGAL/AUTHORIZED > expectations. The server can do things that it can not on port 25. > > If the domain did not send mail with that domain, a NO-MAIL > will cover it. If it signs everything, and it was not, a I > ALWAYS SIGN covers that. If it doesn't sign mail and it was > signed, then I NEVER SIGN > covers that, etc. etc. These are basic fundamental ideas. > > Instead, we are lost in off-topic stuff, lack of expertise in > DNS people telling us the best Lookup Methods and now we lost > in the building of integrated product lines. Come on, give > me a break. Lets get this thing finished. > > Who is the DNS expert here? Lets get the proper best idea > and most practical method for lookup, recommend strategies, > then lets over the syntax and get that completed. > > Then we can begin voting on initial policies to offer. But > lets not get into stupid debates on whether a NO-MAIL POLICY > is worthy or not. Let the sysops decide if that it what they > want or not. > > -- > Sincerely > > Hector Santos, CTO > http://www.santronics.com > http://santronics.blogspot.com > > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
