On 11/10/2005 18:49, Douglas Otis wrote:
On 11/10/2005 09:41, Douglas Otis wrote:
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.
DKIM never assures what is displayed to the recipient. MUAs will
eventually include signing-domains in some manner, as a means to prevent
possible spoofing. This would not be a mechanism to abate spam, as such
control would be done at the DKIM signature or the remote IP address.
Added security at the MUA is not a Final Ultimate Solution for the Spam
Problem. For a small subset of domains, it _may_ be desirable to impose
header restrictions. However, efforts to publish all possible
relationships between signers and email-addresses should be considered
impractical, misguided, and not a solution for spam. Regardless of the
header constraints, spammers will be the first to meet them.
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?
When a percentage of a large ISP's customer base is compromised,
automating the identification and handling of these customers as a means
to redirect them to free disinfection services would reduce both complaint
calls and the amount of spam seen by everyone. Isolating the source of a
problem is not dumb.
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.
Can mailing-lists sign their email without making major changes to these
programs? What percentage would be affected by a From header constraint?
The alternative of white-listing mailing-list IP addresses requires a
significant effort, bypasses protections, and makes mailing-lists
impractical.
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.
Expect domains making a From header restriction to initially be a small
percentage, as this restriction also has significant drawbacks.
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.
When automated, opaque-identifiers could offer a practical solution.
Revoking shared keys will never be practical.
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.
The SSP scheme risks being abused. Will email be deleted or refused
without an SSP? The opportunistic approach would not involve any pressure
to publish. There would be nothing to publish. As such, DKIM could be
ready in less time.
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.
The protocol used to retain the information could be DNS. DNS can publish
names without much additional effort. When local, responses are much
faster and would not require multiple lookups.
This should require less code than needed for SSP. Nor would there be a
need to parse different flavors of DNS records that require sequential
lookups. The information could be determined by the existance of the
record alone. This approach could also establish a class of bindings.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org