DKIM becomes more official

Gary Mills
Sun Oct 14 14:19:03 UTC 2007

On Sat, Oct 13, 2007 at 03:24:43AM +0000, Vernon Schryver wrote:
> > From: Gary Mills 
> > I see from a recent announcement that Yahoo and Ebay/Paypal are now
> > supporting DKIM for e-mail domain authentication.  Their stated
> > purpose is to block e-mail sent to Yahoo users with forged Ebay or
> > Paypal e-mail addresses. 
> [..] 
> The next question one ought to ask is what email Ebay/Paypal wants
> delivered.  For 2 or 3 years I had a Paypal account, before phishing
> became so popular.  I did get a little legitimate mail from Paypal, but
> most of it was junk that I would have squelched if I could...I eventually
> did stop it by giving up on Paypal, albeit less for junk mail than other
> reasons.

We have thousands of users.  The most common e-mail from Ebay/Paypal
is for new passwords or password changes.  These get rejected as bulk
mail, which is confusing to our users.  I'd like to see them be
delivered.  There's also the phishes.  These are apt to fool our
users.  I'd like to see them rejected.  DKIM seems to be the way to
accomplish this.  I have to assume that if Ebay/Paypal announces
they are using DKIM, they are giving us leave to block messages that
don't pass DKIM verification.

> > How should DCC treat such e-mail? 
> I sure that meant "How should DCC client programs treat such email?",
> because Distributed Checksum Clearinghouses have nothing more to do
> with DKIM, SPF, etc. than with sendmail access_db files or DNS blacklists.
> DCC client code can consult DNSBLs and the results of other tests
> including sendmail access_db and DNSBLs can inform the DCC database,
> but the DCC is only about bulk mail.

Yes, I'm using DCC to refer to the whole package, not just the
database.  I realize that the DCC database itself only stores
checksums.  The packages itself, in particular the milter, does
more than that.

>                 .....................
> ] From: John L <>
> ] I don't see that DCC and DKIM have anything to do with each other.  DCC is 
> ] a bulk counter, DKIM is an authentication system.  It is perfectly 
> ] possible to have mail that is bulky and signed, or bulky and not signed, 
> ] or not bulky and signed, or not bulky and not signed.
> yes, and worse, "solicited/unsolicited" is a third independent variable.

When it comes to spam, independant variables are gold.  Bulkiness, RBL
listings, and DKIM are all independant.

> ] Even if you think that SSP will be useful (I personally don't) DKIM can
> ] only tells you whether someone's willing to take responsibility for a 
> ] message, not whether you trust that someone or want to deliver his mail.
> I think Gary Mills is suggesting adding local determinations of whether
> the sender takes responsibility much as DCC client code adds local
> notions of "solicited" to "bulk" to detect spam.

Yes, a manually-maintained spam reputation database would be adequate
for now.  I'd like to see a non-profit and neutral organization take
on the task of maintaining such a database eventually.  It is the other
piece that's required for DKIM to work in general.

>      ........................
> } From: Gary Mills 
> } No, DCC already uses a different mechanism for RBL lookups of IP
> } addresses in various parts of e-mail messages.
> and there are per-user white/blacklists as well as DCC Reputations
> >                                                 I'm proposing a third
> } mechanism for DKIM verifications.  Our users are already familiar with
> } the whitelisting facility offered by DCC.  I'd like to utilize it for
> } DKIM as well as the other two.  I don't want to add a second facility.
> The dccproc/dccifd/dccm whiteclnt mechanism might be useful, but I'd
> be an idiot to start writing DKIM code.  Other people who actually like
> the idea of authentication/bonding/etc. are inventing that wheel.

The only available source appears to be for dkim-milter.  I'm about to
build this for sendmail-8.14.1.  I don't mind running another milter,
in addition to dccm.  In fact, dkim-milter should be fairly
lightweight.  It would have to run before dccm so that it could set
macros, create headers, or something, that could be noticed by dccm.

> DCC client code of several versions ago had hooks for third party
> mechanisms.  The hooks passed the mail message to glue connecting outside
> code and expected ok/reject answers.  I ran some DCC systems for 18
> months with a commercial mechanism similar to DCC, but ripped out the
> hooks when it became clear no one would ever care.  I could rewrite
> those hooks for a third party DKIM module, but I doubt that they would
> see much use.

Are these necessary if the external code is another milter?  The part
that I really need is the user control of rejection.  I don't want two
different mechanisms, one for DCC-determined bulk mail, and another
for DKIM verification.

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

More information about the DCC mailing list

Contact by mail or use the form.