From: "Arvel Hathcock" <arvel(_at_)altn(_dot_)com>
Here's my view and it may be a little over-broad:
* Who are the bad actors?
A 'bad actor' in the context of DKIM is simply anyone who would utilize a
domain name within an email message in a way unauthorized by the domain's
owner.
I agree.
* Where do they fit into the protocol environment (eg, middle of net)?
*
I'm not sure I understand this question but 'bad actors' can inject
themselves into the mail stream at virtually any point I suppose. I could
become a 'bad actor' right here at my office workstation with a very
insignificant configuration change in my mail client.
The most obviously are 3rd party signers, including those who exploit
relaxed provisions in the protocol.
* What are we trying to prevent them from doing?
The focus on 'bad actors' is a somewhat limited view in my opinion but I
understand the culture of the security area in IETF needs it done this
way.
I agree. The questions are very limited.
It's difficult to answer that question in part because what we are trying
to
do is *empower the domain owner* in my view - not handcuff the 'bad
actors'
per se. If I can assert some measure of control over who uses my domain
this has value in and of itself. I needn't worry with trying to define
who
the 'bad actors' are or what creative exploits they may aspire to either
today or the future. But, today, the 'bad actors' are illegally using my
domain to trash my reputation. From the point of view of a domain owner,
that is the entire issue. From the point of view of a message recipient,
'bad actors' reduce the level of faith the public has in email as a
trustworthy medium. DKIM is basically trying to (a) decrease the rate at
which 'bad actors' trash the reputation of domain owners and (b) decrease
the rate at which distrust of the email system is growing.
I agree. The answer is pretty simple. We are trying to stop or prevent them
from spoofing or phishing a DKIM domain.
As you eluded to, there is another critical question here:
* Who are the victims?
There are multiple victims. Not just the domain whose reputation was harmed
but ultimately the end-user who might be worst off with an false illusion of
DKIM protection.
In addition, you have MTA/MDA/MSA or POST SMTP verifiers (where ever you
place it) who may be less scaled, and also may provide false indicators
making it almost worthless to even consider DKIM.
For the record, I agree with Earl's and Arvel's comments here, maybe because
they seem to agree that DKIM seems to require a dual verification concept
for the signer and the verifier to make sure any signing is OA SSP
compliant.
But to me, there seem to be two conflicting forces here:
- DKIM - acceptable protocol that even the DMA can accept
- DKIM - as a "anti-spam/spoof/phish" (ASSP) solution"
without SAYING it is a ASSP Solution
So you are trying to fight one thing, yet make room to allow it. Pretty
tough concept to accomplish without some real big changes. Think Pareto
Optimality. One can not benefit without hurting another.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim