Implications of DKIM signing for DCC filtering?

Vernon Schryver vjs@calcite.rhyolite.com
Wed May 30 18:32:02 UTC 2007


> From: Gary Mills 

> Yes, it's true that a domain owner can sign all of his outgoing e-mail
> with DKIM.  This is actually a good thing.

The question is not whether DKIM is a good thing, because it clearly
is good.  The question is whether it is significant.  SMTP-AUTH and
SMTP-TLS also let a domain owner sign outgoing mail (albeit not via
SMTP relays), but they did not exactly validate the popular claims that
adding authentication to SMTP would be the final ultimate solution to
the spam problem.  DKIM is better that SPF.  It has advantages over
SMTP-AUTH and SMTP-TLS, but DKIM will not significantly reduce spam
including phishing.  The spam problem would not exist except that too
many ISPs do not enforce reasonable terms of service.  ISPs (including
bulk bandwidth providers) that facilitate spam by dealing with spammers
would still facilitate spam even if most mail were signed with DKIM.


> What it will do for me is to allow me to whitelist the verified sender
> domain rbc.com, which happens to be my bank.  I can't do this now
> because 90% of the e-mail from that domain is phishing attempts.

That is a good thing about DKIM, if you make some dubious assumptions.
One is that rbc.com will use DKIM.  They are not currently using DK or
DKIM, but they are using real (-all) SPF markings.  So you could whitelist
their mail based on their SPF RR.  A second problem is whether rbc.com
will send mail only from rbc.com and not from royalbank.com and the
doubtless many other domain names they own.  Mail from other domains
won't get whitelisted, because mail from a strange domain name is the
same with or without a DKIM signature.  A third problem or other half
to the second is that DKIM for rbc.com only helps you receive rbc.com
mail, without making it any easier for you to detect phishing that gets
past your spam filters.


> My bank sends a form of e-mail to me, but I have to authenticate to
> their web site to read it.  This is a response to the unreliablity of
> SMTP e-mail.  It's unavoidable at present.  I'd certainly prefer to
> receive their e-mail in the normal way.

DKIM does little against phishing in general.  For example, phishing
spam from rbankcanada.com could have a valid DKIM signature and would
probably hook many people unless the Royal Bank uses token cards or
other things unrelated to DKIM.  (Just now, rbankcanada.com is not owned
by the Royal Bank of Canada.)


> > good DKIM signature tells you nothing unless the domain name is
> > already known and unless you can distinguish citibank from citybank.
>
> It's true that e-mail recipients shouldn't be expected to distinguish
> between reputable and disreputable domain names.  If the messages are
> signed, the e-mail server can make that distinction.

That assume a broker of good reputations that will distinguish
citibank.com from citybank.com but not from citi.com, which is a
problem in the real world.


> > You might do the same with DCC client whitelisting.  With DKIM
> > checks, you could put example.com in /var/dcc/whiteclnt and not
> > worry that mail forged to appear to come from example.com will be
> > whitelisted for DCC checks.  This assumes that you are among the
> > very few people who worry about that now.
>
> Yes, I'd like to do that now.  For example, we have frequent problems
> with e-mail from travel agents to their clients here being rejected as
> bulk mail.  Users here can whitelist the messages, but only after the
> first one has been rejected. 

That problem is unrelated to DKIM.  Mail from ConstantContact with a
valid DKIM key is welcome by some targets, while the same contents
also with valid DKIM keys can be unsolicited bulk email advertising,
judging from the unsolicited bulk email advertising ConstantContact
sent or tried to send me.

A solution for the DCC rejection of initial subscriptions to travel
agent (or any) bulk mail is per-user dccm or dccifd whitelists and
log files.  It is possible to teach users to check their per-user
logs, read wanted messages that were rejected, and whitelist future
newsletter issues.


>                               domain names are more stable than IP
> addresses, making them more convenient for whitelisting.  I use them
> now, but it would be better if they were rendered reliable by signing.

I think that is mistaken.  The domain names of legitimate mail
senders and some respectable (in some circles) unsolicited bulk
email adverters are significantly more stable than their IP addresses,
but other unsolicited bulk email advertisers go though many domain
names that they may own their own domain name registrars.
(not to mention the "domain name tasting" issue)

DKIM is good for senders with good reputations, but that assumes a
reputation system that reports virtue instead of evil.  It does nothing
for senders with no or bad reputions.  Based on the histories of good
reputation certifiers, a case can be made that a going concern that
certifies virtue is impossible.  Mail receivers don't want to pay to
hear about the good guys, and too many mail senders willing to pay to
have their virtue certified are in the bulk email advertising business
and subject to various pressures to send unsolicited bulk email.


>                                       The other part is to determine
> the reputation of of the domain owner.  I know of quite a few domains
> that I'd like to blacklist if the data were reliable. 

Why can't you blacklist them even with unreliable data?  Who but another
spammer is likely to forge a spammer's domain name?  I think this case
is like parsing Received headers.  You cannot trust any Received: header
except those added by your mail systems to say anything good, because
every other Received: header can be forged.  However, a forged Received
header that says the messages came from pure source of spam can be
trusted.  (You can't use some major DNSBLs including the CBL and Spamhaus
ZEN with deep Received header parsing because while you might reject
all mail direct from a consumer PC, the same IP addresses sending through
their ISP's smarthost has a good chance of being ok.)


> > Depending on how sendmail DKIM support is coded, the DCC `hackmc` script
> > will need small changes or no changes at all for dccm to treat DKIM
> > signatures from senders that sendmail trusts the same as mail with PKI
> > verified certs from senders that sendmail trusts.
>
> I don't think we'd do that. 

That's a good point.  What dccm should be able to do is ignore "ok"
but not "many" markings for domain names in whiteclnt files.


> > As for manual reputations, configuring sendmail to know about some
> > domain names that use DKIM is like configuring sendmail to know some
> > PKI certs for use with SMTP-TLS.  The trouble is that manual reputations
> > don't scale.
>
> Bulk mail detection doesn't scale in sendmail either; it takes a good
> database like DCC has to do it.

What makes the DCC work is that the database is generated without human
attention.  This has important implications that are not available to
manual systems:
  - fewer worries about lawsuits about listings
  - fewer worries that spite, money, business plans, friendship, etc. 
     might affect the data
  - vastly faster reactions to new sources of spam


> > DKIM does little for automatic reputations that is not already done IP
> > addresses.  Automatic DKIM reputations might be useful after most
> > legitimate mail senders publish DKIM keys, but that's not going to
> > happen in the foreseeable future.  Automatic IP address reputations are
> > available today in many flavors including DCC reputations and don't
> > need the cooperation fo mail senders.
>
> That's true, but domain names are more stable than IP addresses, and
> there's fewer of them.  If they were reliable, they would be better
> candidates for whitlisting and blacklisting.

For whitelisting, but not blacklisting.  
And again, whitelisting necessarily involves a manual good-reputation
system and that has scaling and non-technical problems.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.