On Sat, 2005-11-05 at 05:04 -0500, Hector Santos wrote:
Where do you get the "expose expressed desire" that a domain will even want
you to sign its messages in the first place? Does the domain have choice in
the matter?
In my view, DKIM is essentially protecting the email message transport
system. For there to be hijack protection, every message should be
signed by the transport domain. I think there should be three basic
signatures.
See:
9.4 Multiple Signatures
http://www.sonic.net/~dougotis/id/draft-otis-dkim-threats-01.html#anchor25
Even then, it does matter. You have a major threat by avoiding first time
inconsistency. With your idea, a system will need more sampling to get a
better feel. What if its one phish per system attack spread across a tens of
thousands, even a million systems? Are you now going to throw in a RAZOR
like concept into every expanding solution pool so that these participant
P2P systems can learn from each other?
A phish with a look-alike domain would depend upon a reputation service
to deal with that problem. A phish using exactly the same domain, but
unsigned, would represent the status-quo until the phished site starts
signing their messages with the broad-binding (or phished-binding)
assertion. If the domain is not receiving messages from the phished
domain, then any phishing attempts would not be a continuation of a
prior correspondence.
I remember Mike indicating that coverage does not need to be 100%. If
you having not done any business with any-bank.com, it is not hard to
ignore these messages. Perhaps someday, rather than just silly lock
icons, there can be a box displayed that indicates the verified domain.
Why not just reject it with a 451 because of the match failure? If its a
legitimate SMTP system, his SMTP system is designed to retry.
There would be a great deal of valid email that would be rejected with
this logic. An email-address and a signing-domain not matching should
be permitted or many things break. This mismatch will not change upon a
retry. Either you reject or accept it. If you have not seen messages
from a domain previously, you may want to Temp Error to see if they are
using a new domain to send spam. It will not take long to appear on a
reputation service.
Your chart should not offer hostile treatment when email-addresses don't
match the signing-domain, unless they are on a list.
Doug, the CHART has nothing to do with with a LIST, LEARNING, ANALYSIS,
DIAGNOSTICS or BEHAVIOR of domains. The chart simply allows systems to STOP
the CRIME before it happens.
You are stopping legitimate emails in your scheme. You are stopping
messages where the only crime is someone using their alma mater address,
or a list-server such as this one, distributing content. Frankly, the
DKIM signature alone will stop far more crime when the opaque-identifier
is added. The bane of the Internet is compromised systems, and the
opaque-identifier will help a great deal to stop that problem. This
will put an end to the millions of ignored compromised systems sending
malware and spam.
The opaque-identifier provides a means to automate compromised systems
out of existence by reducing tracking efforts by an order of magnitude.
The opaque-identifier would not expose people's identity as SSP does.
The opaque-identifier would only be understood by the provider. They
will understand. : )
The chart offers a theoretical 69% (25/36) hard results with zero
false positive ACCEPT/REJECT conditions. It has 31% (11/36) states
where there is insufficient data to make a hard decision. However, in
these cases, there is nothing to prevent a system or implementation to
augment a pattern recognition learning concept of repeated failures.
Sorry, but this is wrong. You are making rules that brand legitimate
email as bad to claim the scheme works. This scheme does not actually
stop abuse, but instead exposes email-address domains to unfair
reputation. The ones that may benefit would be the mega-domains that
are less likely to be unfairly treated.
Doug, you are totally mis-representing the entire idea of what SSP is
suppose to do. I'm sorry, but I can't help but feel you are doing this
intentionally.
SSP will require senders to add their provider's email-address as well
as their desired return address on the From header to satisfy the SSP
god. Hundreds of thousands of applications will need to be rewritten to
add these double From email-addresses. All of this, while confusing the
heck out of everyone when nothing works as expected?
When they are not on the list, then the reputation of the
signature would simply be evaluated.
There you go again, We are back to a DNA concept.
DNA supports accreditation which is just _one_ form of reputation.
Reputation can mean locally maintained lists, left/right black-hole
lists, and of course accreditation lists. I never said anything about
DNA or accreditation!
Where is the pseudo-code?
What needs clarification? Making a list, checking the list? How
reputation is obtained is beyond the scope of DKIM.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org