----- Original Message ----- From: "Douglas Otis" <[EMAIL PROTECTED]> To: "Stephen Farrell" <[EMAIL PROTECTED]>
>> Requiring a signing domain to maintain such a revocation list >> may be onerous. Say if I get a (bunch of) bogus accounts in order >> to DoS this revocation scheme? > > I would assume that setting up an account would be roughly as > difficult. Doug, as it was mentioned many times which of course, you choose to ignore, your ideas will require a major industry change across the board. DKIM requirs change but not as much as your ideas will require and I don't believe it offers the strength you claim. If you strongly feel it does, I would appreciate it if you provide me with pseudo code or API, preferrably in C/C++, that will allow me to perform a complete software engineering, simulation and requirements analysis. > There can be third-party service providers to publish > revoked opaque-identifiers within seconds of being notified, if this > becomes too problematic for the domain selling such large numbers of > accounts to Bad Actors. Unverifiable Crystal ball prediction with a "Batteries Required" marketing snag. No thank you. > Unlike the centralized approach being described that offers > services to a substantial portion of the world's receiving MTAs, > the opaque-identifier revocation list would be distributed at > each sending domain, where even then only a small portion of > the messages would require a revocation check. So now we have a network of "Member" Distribution? Sounds like the old fidonet nodelist to me where each Friday the "node diff" was distributed across the network to members. Problems: - Is there any restriction on membership? - What if you (senders) don't comply? Do things different? - Who does the sending of this list? - What is the schedule? - Do you have a ZONE, NET, HOST, NODE distribution topology? > There should be less concern at the server. As this > mechanism should be used in conjunction with CSV and reputation, > IMHO, I can say this will mitigate DoS attacks. : ) I thought so. So now we must use CVS AND DNA which is a most definitely a "Batteries Required" disclaimer I must add to my documentation. Sorry. "been there, done that!" We will never add new features again that "Requires batteries" to function, that creates all kinds of support issues when the 3rd party "Batteries" vendors went out of business or has major problems with customers and who also passed the buck to us. We did this before simply because the feature was relative NEW in the industry only a few vendors which little customer support. Eventually, it was dropped, a wasteful high cost development effort. Even if we did consider it, which we won't, the DNS service would have to PAY US a monthly fee for every customer we send its way. No, sorry. Not again. I will never put a cost on customers for obtaining email security. What if a members subscription expires? Do I stop receiving mail for him? Forget about it Doug. To Stephen: The introduction of CVS/DNA helped kill MARID and it will help kill DKIM if this isn't put to a stop. Isn't this out the charter scope? Augmenting DKIM with other mixed protocol requirements with are currently unfeasible protocols isn't going to work. I really hate to rehash all this: 1) We will get into the same chicken and egg problem, what comes first? 821 security or 822 security? 2) CSV requires a fundamental change across the board for ALL mail senders since it is incompatible with 821 current relaxed provisions for HELO/EHLO. 3) CSV conflicts with RETURN PATH verification methodologies. 4) CSV or any HELO/EHLO client domain authentication concept will have an statistically consistent 50-60% overhead since it is the first state point. The efficient is with delayed verification and this is, IMV, incorrectly considered not to be a requirement. 5) DNA has a cost association for implementations and operators. I'm as much a capitalist as the next guy, it would be unethical for us to add a feature to our package with a "Batteries Required" disclaimer. Since we know from experience this will take time before "Free DNA" offerings will be available, I do not would not recommend this for a standard email security idea. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ ietf-dkim mailing list http://dkim.org
