Douglas Otis wrote:
On Thu, 2006-09-07 at 09:59 -0400, Thomas A. Fine wrote:
Douglas Otis wrote:
Not all messages signed by a domain are:
- trustworthy.
- offer valid email-addresses.
These facts poses a basic problem when attempting to convey trust
related information to a recipient by way of annotation. How else is
DKIM to be used?
Well, MAYBE TO PREVENT SPAM!!!! Gaaah!
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.
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.
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.
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.
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.
So some particular application wants some mechanism whereby it
distributes levels of trust in it's email. Why wouldn't they
just add a header line to their mail that says "this mail is
extra-double-secret trusted", and then sign that line along with
everything else?
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.
Please please please give an actual real-world examle of what your
talking about, because everything I read from you sounds like
mumbo jumbo. Just one little real live situation. That's all.
Come up with that, and at least maybe I'll finally understand what
you're talking about.
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
accounts(_at_)BigBank(_dot_)com, for example.
Why would bigbank.com sign a message from accounts(_at_)bigbank(_dot_)com if it
wasn't valid? If it is signed, then bigbank.com is certifying that
it is valid. That's 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.
tom
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html