Dave CROCKER wrote:
Steve Atkins wrote:
The "brand" cannot be protected solely via ADSP, at all, not in any manner.
By that I mean that it's possible to protect the byte sequence paypal.com to
some limited degree, but that that is operationally meaningless without any
way to distinguish between "paypal.com" and "paypa1.com", or between
"citibank.com" and "citibankonline.com",
If anything, Steve is being generous, because it's actually muss worse than
that...
The name variants are one line of attack, with respect to the From: field
address - which is what's being discussed here.
We are taking about Domain spoofs, not phishing. There are two
different set of problem and there was long agreement that DKIM or
POLICY can protect against phishing.
This is about domain spoof protection and nothing more.
But then there are all the attacks on the From: field visible name -- which
is
all most recipients ever see -- the Subject line attacks and the Body
attacks.
None of these is even touched by an ADSP approach.
and no one ever engineered any of the proposed Policy Protocols, from
SSP to ADSP, to address mail alterations as you described. That is
what DKIM-BASE is suppose to do. However, see below.
When someone asserts that a mechanism offers protection, they are obligated
to
account for the cases that are /not/ covered.
Dave, this is a false premise because you are indicating concepts that
were never designed to be part of any policy protocol proposal.
If they are diligent, they will
then assess the relative costs and benefits of this protection proportion,
versus the unprotected proportion.
Again, Policy, since day one, was about Domain Signature practices.
Not about domain phishing nor mail integrity changes. However, since
mail integrity changes are possible reasons for a policy violation,
as RFC 4871 mandates:
invalid signature is promoted as no signature
this allows POLICY and specifically ADSP DKIM=DISCARDABLE to offer
high protection for Author Domains who expect protection against
Domain Spoofs and Mail Integrity Violations at DKIM/ADSP supportive
receivers.
This issue here is whether intermediary signers are obligated to also
support unauthorized 3rd party signing protection sought by ADSP domains?
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html