----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Monday, July 31, 2006 12:43 PM
Subject: Re: [ietf-dkim] Re: 3rd party signing
In
<20060731150944(_dot_)11804(_dot_)qmail(_at_)snake(_dot_)corp(_dot_)yahoo(_dot_)com>
Mark Delany
<MarkD+dkim(_at_)yahoo-
I'm with John on this. I don't see any merit in constructing a system
that allows anomalies soley for the purpose of giving a receiver less
certainty and more work to do.
+1
This is much like the reason I don't like stuff in the rDNS that
indicates that "this machine should never send email". If you want
that policy, do port 25 blocking. Don't make the rest of the world
try to figure out whether you screwed up on your security or you
screwed up on you published policy. And, have to do that all after
receiving the traffic.
-1.
In my view, this is exact philosophy the "bad guy" will be hoping will
become of all this.
If you allow mediocrity to exist, you will get medico as the basis for
abuse. This has been the modus operandi and hallmark of the SMTP mail abuse
problem. That is why we are even bothering with all this.
SSP, if any one has bother to read the specs, or even my specs, offers a
streamlined "no figuring out" deterministic concept of simply authorizing a
purported signature or lack thereof or unauthorized 3rd party signature,
etc.
We were seeing quite of few invalids Domainkeys with fake domains that doe
not exist. Are we expecting DKIM to be exception to this obvious abuse
rule?
Keep in mind, with DKIM-BASE, we have a methodology that says "Ignore
Invalids." How does anyone expect this unprotected methodology to not be
exploited.
With DKIM-SSP, it helps eliminate the high potential abuse of "Ignore
Invalids."
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html