----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
On Nov 4, 2005, at 12:13 PM, Hector Santos wrote:
So what you are saying that is it OK to spoof the From Header as
long as the SENDER is authorized via CSA/DNA?
Not at all. There is a signing-domain centric method that can be
used to establish acceptance criteria as opposed to email-address
centric. Email-address centric risks unfair application of
reputation.
You said that already. So an authorized SENDER now with a signing-domain
centric entity will allow for the continuation of the current free-lancing
and possible fraudulent usage of FROM domains?
The criteria would be limited to that within the signing-
domain.
Ok, ok, I think I am understanding now. :-)
So now, the signing domain now has a "SDP " (Signer-Domain Policy), that he
defines and controls and can use to regulate the free-lancing and possible
fraudulent usage of OTHER domains From Header?
So the email service now defines how the policy of people's property?
For example, you might stop someone from using bgates(_at_)microsoft(_dot_)com
or
mike(_at_)yahoo(_dot_)com but you allow, hector(_at_)santronics(_dot_)com or
user(_at_)public(_dot_)com(_dot_)
What criteria do you use to decide unless you query some domain DNS record?
Or you query a common 3rd party repository DNA service, free, commercial or
otherwise to find out of santronics.com paid his fees?
The signing-domain centric approach imposes fewer
constraints and works far better with exiting practices and
applications.
I don't see that doug. I still have to modify my softare to do a SDP and
now, I have to get product liability insurance in case I am sued by DOMAINS
who claims mal-practice, negligence and possible tortious inteference when
their domains are blackListed due to user abuse originating from my email
service supporting SDP.
In other words, to minimize RISK for SDP, you are requiring all DOMAINS to
subscribe the the DNA service or some SDP repository.
Did I miss something?
The signing-domain centric approach offers a means for
automatic limitations with respect to email-addresses, in a far more
flexible manner than can be achieved otherwise. When captured on-the-
fly, the signing-domain centric bindings also require far less
overhead. : )
You mean an immediate SDP lookup at the point of entry? Neat. So instead of
a SSP lookup, your proposal is to do a SDP lookup.
And of course, the SDP functional specification will offer a policy of some
sort that will allow for an "Exclusive Domain" concept, right?
If the SENDER is authorized, why do we need DKIM again?
As I said, there are exploits reducing the quality of IP address
based mechanisms.
Ok, but if a IP machine is exploited and *DETECTED*, why does anything else
matter? Why should I bother with the payload overhead? and conversely, if
the IP address shows a PASS, but the PAYLOAD is exploited, should that be
enough to broadcast a IP ABUSE blacklist?
What happens of this is a mistake and the fee-paying CSV/DNA domain was
mistakenly blacklisted by the non-supportive CSV/DNA machine because the
DKIM payloaded was deemed abusive?
If DKIM fails, can we blacklist the authorized SENDER via DNSRBL or
using> Local Blacklist tables?
It would likely be a better option to report the event.
To whom? You mean a bounce? Can this create bounce attack threat?
Taking corrective action requires a fair amount of investigation with
respect to possible causes.
True, but in the mean time, I should block the Email Server with the
immediate SDP methodology who allowed malicious users from using other
people's domains that your server could care about - admittely, on the
record, per the specification and intentionally curved in your code.
Correct?
Can DKIM and CSV and DNA co-exist separately? or do you need all
three?
DKIM needs CSV-CSA for DoS protection. This aspect of possible
threats has been largely ignored. : (
I don't think so. I think the consensus is that is a SEPARATE concept. One
can not depend on the other. One can add CSA, SPF or CBV or the next 821
mouse-trap, but that has nothing to do with the payload.
I sincerely doubt DKIM is going to change any system out there that is
currently using a 2821 base technology. There is an awful lot of investment
in IP and 2821 methods. The efficiency is much higher than use 2821 as much
as you can before accepting the payload.
However, they might consider to augment DKIM for the transactions that falls
thru the 2821 cracks.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org