On Jan 25, 2006, at 4:39 AM, Hector Santos wrote:
I think you are underestimating the flip side - receivers won't
bother with implementing DKIM verification. DKIM Signatures -
valid, broken or otherwise, without a concept that is essentially a
"permission or authorization to sign verification" concept, has
little to no value.
This overlooks the value that a verified signature offers with
respect to indicating the true source of the message. Although this
may not be exciting news for an MTA operator, this could be a highly
valuable feature for the recipient when next generation MUAs allow
recipients to register important sources, such as messages from their
bank or broker. SSP is not needed for this type of approach to be
both _safe_ and effective.
We need solid good reason why we should add the check for DKIM
signed messages. A signed message is not enough.
A signed message is better than not having a signed message. The
message signature tells the recipient where the message originated.
Just look at your own broken DKIM signatures in the IETF-DKIM forum.
Sending only to domains on an DKIM-Adopters-List would remedy this
concern. This would ensure signatures are _not_ damaged in transit.
Explain to me why this is an acceptable message over lets say a bad
actor who has learned that its par for the course and will simulate
and emulate your broken message? Further, he doesn't need your
private key. He just needs to fake the signature.
A faked or broken signature would never misidentify the source of the
message by a next generation MUA. : )
How can I protect you?
Filtering for phishing attempts _must not_ rely upon the From email-
address being spoofed. Content filtering needs to compare embedded
links and address information against the DKIM signature. The From
address alone does not provide a _safe_ basis for accepting a message
based upon compliance with some policy. A filter application will
obtain timely, critical identifiers through empirical sources. A
high overhead searching for, and the limited utility of the SSP
record will likely mean there is too little value checking for the
existence of policy a record. There is always value checking a
signature, _especially_ when there is care taken with respect to
where signed messages are sent.
The only reason IETF-DKIM messages is allowed in my system is
because it white listed.
An DKIM-Adopters-List would preclude the need for this effort.
But can I use a broken Jim Fenton DKIM signed messages as a mouse
trap here that are not being sent by this list?
Yes, when the DKIM-Adopters-List is being employed by the sender.
You got to give me solid, logical and deterministic reasons why we
should even bother looking for DKIM signatures - valid or not.
With the use of the DKIM-Adopters-List, all DKIM signatures should be
valid, or they are suspect and _should_ be rejected. This behavior
will allow the construction of private DKIM-Adopters-Lists.
Here is one simple implementation of a Lite Weight DKIM/SSP mouse
trap:
This dog won't hunt. Bad actors are just as able to sign messages.
There is no reason to expect the recipient is able to recognize good
actors from bad actors by what is displayed by the MUA. Assuming
there is a next generation MUA, there will still not be a need for
any SSP record.
The point is, I don't need any DKIM signature verification
overhead. 1 DNS Policy Lookup.
This DNS Policy Lookup will be across several locations for each and
every message signed by a different domain or not signed at all. The
Policy lookup represents perhaps the greatest overhead in this
scheme. All those email-address domains without a policy record also
means there will not be a record contained within the cache to
mitigate this effort the next time a message comes from that domain.
It is not one DNS Policy Lookup, but perhaps hundreds or thousands
before a useful closed policy is discovered.
No need get the public key.
Getting and using the public key would represent a small component of
that overall effort. Much less than that associated with the SSP
record.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org