Dave Crocker wrote:
The sequence matches what is already specified in the DKIM
draft charter <http://mipassoc.org/dkim/dkim-charter-05dc.txt>
Apparently many / some (?) participants here prefer to consider
DKIM only in conjunction with SSP, not as an isolated solution.
This makes sense, the draft charter claims:
| Forgery of headers that indicate message origin is a problem
| for users of Internet mail. The DKIM working group will
| produce standards-track specifications that permit
| authentication of message headers during transit
Thanks to some very interesting threads here I now begin to
understand that DKIM on its own without SSP is unrelated to
the draft charter:
Apparently all DKIM does is to allow arbitrary in-transit
parties to "sign" whatever they claim to have got "somehow".
Or in other words what the spammer personally forged, and
what the checking party gets is a related d= domain owned
by the spammer to send abuse reports to.
This is a waste of time and bandwidth, it has nothing to
do with header fields indicating the origin. Maybe I just
don't get the idea, but apparently Jim could send mails
with "From: nobody(_at_)xyzzy". They'd be signed by Cisco and
would result in a DKIM PASS.
Of course he won't do this, in that case an abuse report
should have an effect, and it's still possible to block
this source.
But spammers don't care, they have throw-away domains and
create a DKIM PASS almost as easily as an SPF PASS. They
are also not in the habit to act on abuse reports, they
use the cheapest black-hat registry they can find, or use
phished credit cards to register their throw-away domains
with bogus whois info.
DKIM on its own is of very limited value, it might help
to manage white lists or as a base for reputation - but
that is explicitly off topic in the draft charter.
SSP should be the first point, before we waste time, and
the question of "no SSP => all signatures about affected
domains in From or Sender headers are bogus" should be the
very first issue.
I've had it with all "opt-out" schemes, sorry. Bye, Frank
_______________________________________________
ietf-dkim mailing list
http://dkim.org