On Sep 7, 2006, at 10:07 AM, Thomas A. Fine wrote:
Douglas Otis wrote:
DKIM can not prevent spam!
If yahoo uses DKIM, then DKIM can prevent forged spam from yahoo.
That's HUGE! Spam from valid users is something yahoo can easily
control - and if they fail to do that, they risk blacklisting.
That same principle, across most domains, together with a good
blacklist would eliminate the vast majority of spam we're seeing.
Yahoo!'s use of DKIM will not prevent spam purporting to be from
Yahoo!. There can be messages that appear to have been submitted to
a mailing-list, or replays of messages. DKIM offers few methods to
identify a message as being spam. DKIM offers a means to verify the
particular domain from which the message had been signed. While
allowing for annotations that assure the recipient, DKIM still does
not prevent spam, even when purporting to be from a domain that
claims to sign all messages.
Do you have any idea how bad spam is? 80% of all the email we
receive is spam! Our mail server is so overloaded, it keeps
shutting down sendmail so it can catch up on spam processing.
We're being forced to install new hardware to cope. We waste a
HUGE amount of daily staff time on spam.
About 70% of that 80% abuse is being sent from compromised systems.
Tens of thousands of stolen credit card numbers are being used to
establish email accounts every day as well. If DKIM is going to make
a difference, it will be with respect to reporting and preventing
common spoofs through the use of DKIM annotations in combination with
the address book, and perhaps trusted domain lists and high level
assurance annotations.
So if I seem particularly annoyed on this list, it's because I've
been waiting for domainkeys/dkim to grow up enough to be a leaky
dam (better than the sieve we have now), and then I look at this
list, and I see people wasting time on user keys that will never
work anyway, and it makes me really angry.
Stopping people from clicking on malware, or filling out financial
information is absolutely essential in fighting spam. Assurance
annotations that DKIM provides should become a gold standard people
insist upon seeing before taking actions suggested in an email message.
DKIM is transparent to the recipient. DKIM is unable to block
messages from bad actors. DKIM does not even safely allow white-
listing from large domains where there is risk of replay.
I think you think I want a perfect whitelist/blacklist. I don't.
If my whitelisted domains produce a little spam, so what. Our email
is 80% spam!!! If I can reduce that number to 10%, I'm thrilled.
I want a DKIM that gives us the tools we need to reduce
spam.
While there are a limited number of IP addresses, there are also an
unlimited number of new and used domains that can be obtained at
little cost. The concept that DKIM in conjunction with white/block
listing will make a dent in the amount of spam is simply wrong. DKIM
should improve reporting and help prevent spoofing, nothing more.
There MUST be an application layer to convey which messages are
offering some form of DKIM related assurance. This could be that
an assured valid email-address is also contained within the
address book. It could also be that a trusted domain
categorically assures an email-address. Either scheme offers
valuable protection from common spoofing.
The fact that your email shows up at my email server signed by your
email server is all the protection I need or want. At that point,
I can use my own internal policies to decide if your domain is
trustworthy or not, based on our experience with you and/or your
internet reputation.
To prevent disruption of email services, your system will also
continue to accept messages that are not signed, and that have
signatures that appear to have been damaged. Perhaps only when an
email-address domain makes an extreme assertion all their messages
are assured to have a perfect signature, would there be a basis to
block those messages. Every other look-alike or cousin domain will
still be accepted. Without annotation applied to signed messages,
the recipient will not have been helped at all.
The only control a domain has with respect to DKIM signing is over
the use of the email-address. DKIM signing can happen at the MTA
and the MUA. The only way to say "Trust this message" would be by
way of the email-address or some added assertion made within the
key/signature.
No, "trust this message" happens when the domain signs the message.
If a domain is silly enough to hand out it's private key like
candy, and let all of it's users sign their own keys, then they're
likely to be compromised often, and to have a bad reputation.
A large domain like Yahoo! will perpetually have a moderate
reputation, largely due to their size and ease of obtaining an email
account. Does this mean that Yahoo! can never be trusted on the
basis of their domain? Most would trust a message that Yahoo! backs
with a high level of assurance. Perhaps [EMAIL PROTECTED] could
receive a high level assurance. This high level assurance might be
deduced by specific email-address policy this email-address is
"STRICTLY ASSURED TO BE SIGNED." A message signed by Yahoo! and
given a high level of assurance should become a minimal requirement
before anyone follows actions suggested in an email, at least without
other out-of-band information.
Perhaps Yahoo! wishes to request their users to go to a web-page and
update a compromised browser toolbar. If this were a message from a
bad-actor holding one of their accounts and people responded based
solely upon the Yahoo! signature, this would be very bad news
indeed. High level assurance annotations offer vital protections.
BigBank.com is being heavily phished. An MUA vendor wishes to
offer different levels of assurances to combat phishing and to
restore trust in their messages. BigBank.com is large and has
many new employees, and must deal on occasion with compromised
systems. BigBank.com would like to limit the risks associated
with high level assurances being offered as a feature of the MUA
vendor. It asks the MUA vendor to limit these assurances to only
those messages from the email-address [EMAIL PROTECTED], for
example.
Why would bigbank.com sign a message from [EMAIL PROTECTED] if
it wasn't valid? If it is signed, then bigbank.com is certifying
that it is valid. That's enough.
One should not expect the recipient to be able to even recognize the
email-address. One should not expect all messages being signed will
have valid email-addresses, or that they are from trustworthy sources
either. A signature alone is never enough.
It is not DKIM's place to solve the internal security problems of
bigbank.com. And I don't see how user-signing could help, even if
it was DKIM's job to do that.
It is not user policy, but email-address policy that is significant.
If BigBank.com knows that <[EMAIL PROTECTED]> is trustworty, but
that other emails-addresses are less trustworthy, how should that be
conveyed? By not signing the other messages? That would be silly.
BigBank.com can however make extremely strong assertions about
<[EMAIL PROTECTED]> that would be highly disruptive when applied
to other addresses. This could be done solely to increase the level
of assurance annotations this message receives. Assurance
annotations offer a proactive means of preventing broken signature
and look-alike attacks.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
