On Feb 7, 2008, at 12:34 AM, Hector Santos wrote:
Douglas Otis wrote:
DKIM is not an anti-spam technology.
Yeah, right. <wink> <wink>
Doug, how are you (speaking in general) going to stop vendors from
putting it in Anti-Spam or Security sub-sections of their products?
Or stop them from advertising or marketing it as new "anti-spam/
security features" Or stop the rags from speaking of it as the new
"great" ANTI-SPAM solution?
You won't, you can't. In fact, just read the abstract in the draft
Deployment Guide by Dave Crocker and Tony Hansen:
Such protection of email identity may assist in the global
control of "spam" and "phishing".
Disagree. DKIM/SSP offers a means accurately categorize messages
into:
a) valid first-party signatures
b) without valid first-party signature from a domain that signs all
c) without valid first-party signature from a domain that guards
their signature
d) valid third-party signature
e) valid third-party signature from a domain that signs all
f) valid third-party signature from a domain that guards their
signature
and yet fails to detect fraud and the bad guys doesn't have to do a
thing.
DKIM places bad guys into smaller categories. This placement allows a
greater amount of resources to be focused upon questionable categories
such as "b", "c", "d", and "f", and of course "c" and "f" especially.
The resources need to inspect for spam, phish, and malware is limited
where triage is often required. DKIM helps in better allocating
limited resources.
If the public key is NULL, the DKIM signature is automatically
invalid and if an ASP DISCARDABLE policy is used, it means
REJECTION.
Does "discardable" mean rejection?
Is this a rhetorical philosophical question, right?
This is a serious question.
Although a domain should be able to use SSP to indicate their
behaviour, SSP should not be used to dictate verifier actions.
So why does it promote the idea of MX checking with a MUST action?
This MX check is to determine the existence of a domain using a record
likely to be present. This just improves caching rates.
I fail to see why someone would invest in this where there is no
payoff - a payoff of eliminating a high volume of BAD mail and at
the same time enhance the quality of what it receives and passes on
to users with a higher degree of confidence. I think there might a
flawed presumption that receivers are going to do things where there
is little benefit in return.
DKIM reduces false positives for anti-phishing filtering. DKIM also
allows a high percentage of the messages to bypass more stringent
checks when the source of the message is trusted and the message body
is _fully_ signed.
If the DOMAIN says it doesn't expect 3rd party signatures, it
would be incredibly dumb for a Receiver to ignore those factors,
not just for the good of the domain which has implicitly stated it
would not take responsibility for a message it did not write or
sign, but for the receiver and its users as well to not use this
unique detections to get rid of something that is clearly fraud or
unauthorized or unexpected by the domain.
Agreed. That is what "strict" was about. However, there may be
other factors a verifier might apply in deciding the disposition of
the message. There is no reason SSP should enumerate actions that
might involve extraneous factors. That should wait for a BCP draft.
How can you agree here but disagree with other statements that
basically said the same thing? <g>
SSP must avoid becoming a BCP. SSP should provide information about
what the signing domain does. FULL STOP.
I am not talking about nothing more but the three obvious frauds:
No Mail Expected
You are right. This is a common spoofing method. The number of
transactions used by DKIM validation in deflecting this abuse is
critical.
Mandate the publishing of MX records whenever SSP records are
published and when email is used by the domain.
By searching for SSP policy records, the question of email use can be
determined without any additional transactions required. It would be
negligent to not mandate publishing MX records when also publishing
SSP records. Mandating the publishing of MX records in conjunction
with SSP records reduces the number of DNS transactions expended on
DKIM signature validation in the case of domain spoofing. This
mandate is easily justified as a resource safety issue at least.
Publishing MX records for email is a good thing from both a policy and
reliability perspective.
Signature Expected by anyone
Sorry, this is the default situation. SSP is not needed here. Be
happy there is more verifiable information at least.
Signature Expected by the Primary/Author Domain only
This would be what the now missing "strict" assertion would have
provided. Unfortunately, this role can not be safely provided by
"discardable" instead.
IMV, these are indisputable 100% zero false positive first level
protocol inconsistency detectable checks and will offer a high
benefit to DKIM signers of all market types, specially exclusive
high-value commodity domains that don't expect any other
unauthorized usage of their domains and will offer an immediate
impact of domain protection against fraudulent legacy transactions
right out of the box.
I agree with you on the last point.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html