ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] RE: I think we can punt the hard stuff as out of scope.

2007-06-05 12:34:24
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:hsantos(_at_)santronics(_dot_)com] 
Sent: Tuesday, June 05, 2007 3:23 PM
To: Hallam-Baker, Phillip
Cc: Michael Thomas; Scott Kitterman; ietf-dkim(_at_)mipassoc(_dot_)org
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

<Prev in Thread] Current Thread [Next in Thread>