ADSP is all about what happens when there *isn't* a signature. How do you
determine the scope of the policy? No enterprise on earth would say that
they want to have thousands of touch points for that.
Of course not. You treat mail from
eliot(_at_)ams-iport-1(_dot_)cisco(_dot_)com the same
way you treat mail from eliot(_at_)cisco(_dot_)services(_dot_)net, most likely
scepticism. You can't blacklist your way out of the lookalike domain
problem; you can only whitelist the domains you have some reason to trust.
And perhaps the best approach is for us to find a room at MAAWG and talk
If you want. But it's still not going to change the dismal fact that you
can't blacklist your way out of the lookalike domain problem.
Reputation portability is indeed important, but I don't see why one
would want to implement it by default fuzzy domain matching, with all
the phish vulnerabilities that opens up, particularly when DKIM
already provides straightforward workable ways to do it.
Why do you say the matching is fuzzy? Again, we're talking about the case
where the signature is not there.
I get a lot of mail from cisco.com, and I have an opinion about mail from
that domain. ADSP might even help me refine my opinion about mail from
cisco.com that doesn't have a signature. But whatever my opinion about
cisco.com is, it does not extend to other domains that resemble cisco.com,
even those domains that happen to contain the string cisco.com in them
somewhere. That's the fuzzy matching nobody's going to do.
As I've been saying over and over, there is no reason to give subdomains
the same mail reputation as a parent domain, and a lot of reasons
NOT to do so. If you want to share reputations, DKIM signatures let
you do so by sharing signing domains.
NOTE WELL: This list operates according to