ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: dkim.org (mipassoc.org/dkim) web page updated

2005-11-10 16:56:39
On 11/10/2005 09:41, Douglas Otis wrote:

No matter what you do with hueristics, you are only modulating an
approach that will only ever be so good.  What we need is more
deterministic solutions and less dependence on heuristics.

What would you use when all spammers sign their email where their From
matches the signer?

First, I'm not saying a don't think heuristics will always be necessary.
They will.

Second, then they aren't sending e-mail from my domain anymore.  That's a
victory.


When DKIM signature represents the sending domain, there is no need to
examine other headers for this determination.  Eventually, MUAs should
note the normal signing-domain associated with an email-address listed in
the address book.


Third, now I have a good name basis for blacklisting.  That's a victory.

The DKIM signature alone permits white/black listing without the need to
examine other headers for this determination.


Fourth, yes, they can go register new domains, but adding DKIM to the mix
increases the complexity/cost of solving the problem for them.  The more
expensive spam gets, the less of it there will be.

The majority of abusive email comes from compromised systems.  In fact,
many spammers scale horizontally at trickle rates to avoid detection. 
DKIM alone will not offer a reduction in spam.  Isolating compromised
systems when the spammer uses the ISP's server is where DKIM with an
opaque-identifier could be highly beneficial.


My original point was that if you take a unitary hueristic analysis and
break it into two parts (content and name) it doesn't necessarily give you
a better result.  It may be marginally better.  I think it's unlikely to
be substantially worse, but it's not at all clear to me that it's enough
better to be worth going through the hoops you are proposing.

I think just the DKIM signature allows for substantially better results,
and verifies the name that is being trusted for even greater value.  By
not requiring a From/signer association, current practices can be
retained.  Forcing the use of double From email addresses is a hoop you
want imposed that would provide little value, while creating a fair amount
of disruption.


What is the desired goal that requires this sizable effort for managing
these white-lists and extra email-addresses?

It's a work around if the working group doesn't come up with a
satisfactory solution to mailing lists breaking DKIM signatures.  The
desired goal would to avoid going to the effort of attempting to validate
signatures that aren't going to validate.

Why not allow the mailing-list to sign their email without imposing other
changes?  The required association of From header with the signing domain
is standing in the way of a rather simple solution.   Signing without
regard to the From headers would not require the modification of thousands
of list-servers and MUAs applications.  Nor would this require an
inordinate amount of white-listing by address.

During early deployment, broken signatures will likely require the event
to be logged and then passed along.


Abuse@ emails or even phone calls provide you feedback.  If this
feedback is about message replay abuse, then being able to curtail and
even prevent replay abuse ensures this does not become a common exploit.
Self revocation shares this valuable feedback.

OK.  So what you are saying is that replay protection has value
independent of reputation service?  I can see the potential in that.

I am glad you see the value in this mechanism. :)


You are advocating changing email practices.  Allowing current practices
is not a tangent.  Perhaps the MUA address book could also capture the
signing-domains to detect possible spoofs without forcing a general
association of the From/signer.  It seems From/signer restrictions only
make sense for a small number of domains.

Sure I am.  I think e-mail is broken enough today that things have to
change (can't make an omlette without breaking some eggs).  The question
is how. I'd like to change e-mail so that fraudsters and spammers have
less success.

By the time you get to the MUA, IMO, the battle is over.  SSP is an MTA
level tool to solve an MTA level problem.  I'd rather keep the users out
of this entirely if possible (I know it won't be possible, but it should
be minimized).

I'm not sure how many domains From/signer restrictions make sense for.  I
am confident that the number is non-zero.  Restrictive SSP should be
allowed, but not mandated.


Don't make DKIM to expensive to deploy.  Once the From normally differs
from the signing domain, then how policy gets distributed becomes a
greater consideration.  In those cases of an independent From, the need
for additional policy does not exist.  An "opportunistic" capture of a
smaller number of policies will involve far less overhead, especially when
policy is seldom published.

This approach would log signed assurance/non-assurances (bindings) that
the From, within the same signing-domain is signed by this domain.  The
domain name would be added or removed to/from a name-list in a local
resolver.  This removes the many DNS lookups per message and replaces this
process with a local lookup that should resolve in microseconds rather
than seconds.  It would also be easy to share this information among
servers/providers.

-Doug






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