ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP security relies upon the visual domainappearance

2005-11-20 20:26:21
On Sun, 2005-11-20 at 15:44 -0500, Hector Santos wrote:

How is a look-alike domain rejected by comparing the From and
signing-domains?

Signature/SSP valid or invalid?

invalid --> reject
valid   --> accept

Pretty much use the SSP Verify Chart for a guideline.

From Ebay accounts <accounts(_at_)corporate(_dot_)ebay(_dot_)co>
singing-domain: corporate.ebay.co
valid --> accept

Think of a few dozen variation of this name involving just ASCII and
multiply that by the hundreds of TLDs.  While large companies may make
this expenditure involving tens of thousand of dollars each year for the
registration, many of these domains will require litigation before such
domains can be acquired.  Depending upon the size of the company,
success in such litigation may be limited.

So again how is a look-alike domain rejected?

The caching of automatic binding assertions would be a means of
acquiring a requirement that a From domain must match a signing-domain
and then using this to reject messages that fail this requirement.  That
would only be half the effort needed for providing spoofing protection.
Extending this protection requires binding advice provided within the
signature.

The goal is to "recognize" important correspondents as insurance against
spoofing.  Bad Actors are still be able to meet any DKIM requirement
including either an automated binding assertion or '0=!' policy.  Some
companies register thousands of look-alike domains.  With puny-codes,
the effort and related expense becomes largely futile.  Why not develop
a system that does not require the eye-test or the registration of
thousands of similar domains in hundreds of TLDs?

In unrelated comments with respect to reputation, the focus must remain
on the email sender and not the email-address.  A general goal must be
to hold the administrator accountable.

-Doug

_______________________________________________
ietf-dkim mailing list
http://dkim.org

<Prev in Thread] Current Thread [Next in Thread>