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.
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?
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?
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.
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>
I am not talking about nothing more but the three obvious frauds:
No Mail Expected
Signature Expected by anyone
Signature Expected by the Primary/Author Domain only
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.
Nothing more. Really, nothing else. They are fundamental ideas that
basically applies to a new level of transactions that is either true or
false and nothing in between.
It is like the EHLO command. In normal Port 25 transactions, the BCP is
that it is a weak consideration to apply strict compliance on this
command. But by raising the bar with the SUBMIT protocol (port 587),
the SMTP receiver has new technical and legal rights that is not
possible nor feasible with the public PORT 25 standard SMTP transaction.
So when a domain steps to this level, there is a new level of
expected behavior with hardly any questions asked if the sender does it
wrong!
DKIM + POLICY does the same by raising the bar at the x822 level with a
new level of expectations that is either TRUE or NOT. The above three
policies provides this fundamental idea. It moves the transactions
beyond the 20+ year old relaxed legacy considerations that was the
essence of the spam problem we have today.
Doug, you were militantly vocal against SPF for the same SOFTFAIL
reasons. As sure as the New York Giants are Super Bowl Champions,
then you will be having belated recognized issues with ASP::DKIM=ALL
failures as well. :-)
SOFTFAIL is never having to admit the protocol itself is broken. : )
Trademark it! <g>
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html