----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
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