On 11/10/2005 18:49, Douglas Otis wrote:
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.
And unless there is a tie to a header that's actually displayed, it's
irrelevant. Saying that eventually MUAs... is just another FUSSP. I'm not
holding my breath.
The only way to force signing domain = From domain is SSP. So your "When DKIM
signature..." doesn't happen without SSP. There's no motivation.
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.
I guess my view is that if the ISP is dumb enough to sign their spam, then to
bad for them.
If I were to implement DKIM, I'd be very careful about which MTAs had the key
to sign my mail.
I don't see you're opaque-identifier being particularly helpful here. The
real issue with trickling through ISP MTAs is detection. I thought you were
claiming that the opaque-identifier was for replay abatement?
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.
I agree that you think that. I don't agree that you are right. Please show
us the analysis that backs up your claim. It isn't inevitable.
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.
The required association between the signing domain and the From header field
also stands in the way of a lot of misuse of domain names in From. It may be
necessary for domain owner to pick.
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. :)
I see value it replay protection. I don't know that your scheme is an
effective way to go about it. I also don't know that the cost/benifit is
there for replay protection of any type, let alone yours purported scheme.
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.
OK. If your scheme works better (I don't think it will, but I am wrong
sometimes) then that's what will happen. No need to derail SSP now to
achieve your vision.
Let those of us who are interested work on SSP. You work out your theory.
Let the market decide in the long run.
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.
So, you've designed the protocol that makes it "easy to share this information
among servers/providers"?
Once again, this only works for the big boys. It's of no interest to me.
Scott K
_______________________________________________
ietf-dkim mailing list
http://dkim.org