Implications of DKIM signing for DCC filtering?

Gary Mills mills@cc.umanitoba.ca
Wed May 30 14:21:42 UTC 2007


On Tue, May 29, 2007 at 09:37:48PM +0000, Vernon Schryver wrote:
> > From: Gary Mills 
> 
> > I've just been reading about Domain Keys Identified Mail at:
> >
> > 	http://dkim.org/
> >
> > It's quite impressive, although it has some intentional limitations.
> > I'd expect that companies that are frequent `phishing' targets, such
> > as banks, will start signing their e-mail as soon as they can.
> 
> Yes, and spammers and others are already authenticating their mail with
> DKIM and SPF.   With DKIM, targets of phishing will still not distinguish
> between citybank.com and citibank.com.  They will still swallow not
> quite plausible bait and cough up their account numbers, social security
> numbers, user names, PINS and so forth.

Yes, it's true that a domain owner can sign all of his outgoing e-mail
with DKIM.  This is actually a good thing.  Signing makes the sender
address, at least the domain portion of it, reliable.  Verified sender
domains can be whitelisted or blacklisted.  This is much better than
the domain owner forging somebody else's e-mail addresses as the
sender.

> DKIM, SPF, and similar sender authentication schemes cannot and
> will not do anything significant against phishing.  Knowing that a
> mail message was not in some trivial sense forged tells you nothing
> about whether you can trust what it says.  This equivalent to the
> ancient mantra that a PGP signature shows that the message is good
> but not that the sender is good.

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.
Common e-mail clients only display three e-mail headers to users,
making it very easy to fool them.  This is a very serious problem
in our environment.

> To stop phishing with some sort of authentication, you probably would
> have to reverse the handshake and authenticate customers to service
> providers with mechanisms that cannot be copied like PINs.  Some banks
> in Europe are reported to be distributing token cards to force customers
> to authenticate themselves to the bank and as a side effect authenticate
> the bank to the customer.

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.

> > How will DKIM signing fit into DCC?  I assume that DCC will be a good
> > place to verify signatures.  Should signed and verified messages be
> > exempted from bulk mail rejection by DCC?  I assume it's not that
> > simple.
> >
> > Organizations that sign e-mail messages must take responsibility for
> > those messages, but I assume that the level of responsibility will
> > vary.  In the case of a bank, the e-mail senders will be employees,
> > but in the case of an ISP, they will be customers.  The relationship
> > between the organization and the e-mail sender is quite different in
> > these two cases.  There will also be some organizations whose business
> > is sending bulk mail.  I can see a need for reputation ratings, along
> > with whitelists and blacklists of domain names.  How much of this wil
> > fit into DCC?
> 
> Authentication of a message from stranger is the same as no
> authentication at all.  Authentication makes sense only in the
> context of other messages from the sender.  That a message has a
> 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.  Likewise, e-mail
recipients shouldn't be expected to identify bulk mail by looking at
their single copy.  That's why we have DCC.  These are both things that
computer systems can do much better than people can.

> The only sane use I've heard of for DKIM is to help ISPs like AOL manage
> whitelists.  Instead of use a list of IP addresses and updates when the
> list for a sender changes, AOL might watch for domain names on a list
> of trusted mail service providers and check DKIM signatures for those
> domain names.
> 
> 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.  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.

> Using DKIM that way would be just like configuring sendmail to know
> about some PKI certs or SMTP-AUTH keys and fixing sendmail.cf with
> hackmc to whitelist mail with valid SMTP-TLS or SMTP-AUTH keys.  Just
> as you would not whitelist mail that arrives via SMTP-TLS but with a
> certificate that you cannot verify, you would not whitelist mail from
> a stranger merely because it has a good DKIM signature.

Yes, DKIM is only part of the system, but it's an invaluable part.
It makes the sender domain reliable.  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.  It would be
good if DCC could cooperate in this endevour.

> Given Eric Allman's interest in DKIM, I assume that sendmail will soon
> be able to treat DKIM signatures like SMTP-TLS or SMTP-AUTH authentication.
> 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.  I assume, however, that sendmail will be
able to sign messages with DKIM.  We might use it to sign outgoing
e-mail that was submitted by local users with SMTP authentication.

> 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.

> 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.

-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-



More information about the DCC mailing list

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