DKIM becomes more official

Vernon Schryver vjs@calcite.rhyolite.com
Sat Oct 13 03:24:43 UTC 2007


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

I think they are being disingenuous, and that their real purpose
is to get email from Ebay/Paypal delivered to Yahoo mailboxes whose
owners would otherwise blacklist everything with any hint of
Ebay/Paypal.  It's been years since every mailbox in my vicinity
stopped accepting anything claiming to be from Ebay/Paypal.

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.

>                           This implies that Yahoo will be blocking
> e-mail that has these forged addresses.

If you believe that, than shouldn't you believe that Hotmail will
start blocking mail that SPF says is forged?  I'm again publishing
SPF RRs because of a torrent of Russian backscatter.  I've seen no
significant effect, except that it gave me an opportunity to discover
that the response to SPF hard-fail by Google and Hotmail is to
deliver, with no indication at all of any problem.


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

                .....................

] From: John L <johnl@iecc.com>

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

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

My personal prediction about sender authentication/bonding/etc. is what
I've been saying for years, that those who will use and pay (in time,
money, bugs, bandwidth, CPU cycles, etc) for it have big delivery
problems that are costing them money.  That applies in the current case,
but not only as the optimistic might assume.  My recollection of Paypal
is that email is not really needed, and that the reason Paypal wanted
to use email was for advertising.  I've never used eBay, but I wonder
if the same applies, whether you strictly need email *sent by eBay* to
participate as buyer or seller.  Even if so, that would seem like an
artificial restriction intended to bind users.  If you've really got
to send or receive "push" advertising, DKIM sounds great.  If you prefer
"pull" advertising, you'll never have much use for authentication/bonding/etc.

     ........................


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

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.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

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