On Nov 1, 2005, at 8:23 PM, Hector Santos wrote:
DKIM requires change but not as much as your ideas will require and
I don't
believe it offers the strength you claim.
Binding an email-addresses to the provider and prohibiting third-
party services such as list-servers is a change being required by
SSP, once the effects of reputation are considered. The message
replay abuse problem still has not been resolved, which should be,
once the effects of reputation are considered. I can see why no one
wants to consider reputation. Once you include the effects of
reputation, the SSP mechanism falls apart.
There is not much value in DKIM without being able to use the
verification of the signature as a basis for accepting messages. I
don't care what is _in_ the message, provided the administrator of
the system gets rid of abusers. Simple and the signature makes it
very clear where to complain. Sweet. What you want is far more
disruptive by insisting that an email-address can only be carried by
a particular email message transport system. Of course this only
changes the nature of the problem, while offering no real solution.
It is nutty to think that abusers can not sign emails to continue
spoofing domains unabated.
You worry about being excluded, but the only way this approach works
is within a closed system. Shut down the registrars, there are
enough domains in use. ; )
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?
It is clear that you have not understood the mechanism. The opaque-
identifier and related revocation would be an option for domains that
experience a message replay abuse problem and want to mitigate the
damage it may have on their reputation. Of course, the domain could
elect to ignore the problem and hope their signature still offers
some acceptance value. Most, I suspect, would see value in defending
their signature.
The revocation record would be self-published within their domain in
the same fashion as the keys. If the task of publishing the
revocation records proves too burdensome, they could delegate the
revocation zone to a provider that specializes in providing the
service, perhaps in conjunction with Abuse-Feedback Reporting (AR).
I doubt most domains would see a replay problem rise that that level.
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.
When defending the DKIM system against a DoS attack, the CSA
mechanism offers a solution. This same record can also make a server
level assertion that all transports from this domain must have DKIM
signatures. If not, it is not us. This could defeat some routing
exploits. If you read the documents I published, this is explained
as a mitigation strategy for DoS and Replay issues. I don't see how
batteries are required as the CSA record is far less complex than the
SSP record. Neither of these records would be seen as a dependency
for DKIM?
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.
Again it is clear by your statements that you do not understood the
CSV-CSA mechanism which is surprising. I see DNA as perhaps out of
scope, but not beyond merit. CSA records however could offer name-
based DoS protection. Whether this solution gets mentioned would be
a tough call in my view. I still think these options should be
considered and what problems they prevent.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org