----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
The limitations of specifying the relationships between signing-
domains and email-address make SSP impractical. Once SSP is
attempted however, one can expect that compliance will be coerced
where everyone must give up on seeing the email-address be
independent of the signing-domain, and where many things break.
You have a very verbose way of saying that a Sender Authorization Framework
is the way to go here, a "Chain of Trust" concepts across the board.
What I think you fail, no, choose to ignore, no, forget?, whatever, is the
issues of compliancy.
As a SMTP vendor, how am I going to support backward legacy issues?
It really doesn't matter what method is invented, in the end, the issue of
backward legacy issues is still a major problematic issue.
I see DKIM is a relative simple "addition" that can raise the bar for
DOMAINS who want to assure that their DOMAINS are not used outside their
authorized SENDER network. SPF is the same idea, DKIM does it differently.
The key, which is what I think you realized is strategically competitive to
your DNA service ambitions, is that DKIM can work really well by using a
lookup concept, not to a REPUTATION system, but to the DOMAIN policy
statement.
I think you are concern this will reduce the need for reputation systems.
I don't think you have anything to fear because it might be required for
RELAXED DKIM provisions, but as a independent feature, not dependent feature
for DKIM.
What I was trying to explain is that if this is the case, and I don't argue
against it, is that inevitably, it brings you down to a 821 level.
Reputation will trump DKIM and if we want to go down this route, then DKIM
is really not necessary.
But then we get into the marketability and the asthetics of the "reputation"
concept. I don't think it plays very well in the open-standard EMAIL
infrastructure. It is very difficult to sell an "add-on" feature that will
have any cost associated with it, and even if there isan't a cost or there
are plenty of free systems, then you have a dependency issue of waiting for
this to happen and you also run into even more reputation problems for the
reputation system itself.
Case in point: DNSRBL
In the beginning, we used your fine MAPS system. But then you went
commercial. This created a PR and Marketing problem for us. I didn't have
a real problem with it, but now we had to change our software to make it
list based so the sysop can define the RBL sites. At first, there was only
1 good free system, relay.osirusoft.com. But then he feel victim in the
now famous SORBIG dual attack of bringing down RBL sites and injecting
BOUNCE attacks into the network. What did the osirusoft.com do as PAYBACK?
He rejected EVERY request. Mail was being lost all over the place.
Now we have to find new sites to offer to customers, etc, etc. Today, it has
all stabilized with some reliable sites and by default, we offer:
CheckRBLSite sbl.spamhaus.org
CheckRBLSite list.dsbl.org
CheckRBLSite bl.spamcop.net
but we had to couple it with a smart site order lookup timing algorithm
concept in case any of those are down or are SLOW to react.
I don't know the sales business model for MAPS. I'm sure it is successful,
but I don't think you can propose this or anything close to it for a
standard operation in an open-standard world wide INTERNET mail system.
Even then, do you think you are going to convince people like me, including
operators that they should abandon DNSRBL lookups.
I don't think so. That's my opinion, not necessarily because it doesn't
have technical merit, it does, but because it is full of secondary and
tertiary issues.
Again, just my input on the matter. I think it will hurt the DKIM process if
is becomes a basic requirement.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org