Re: Shocker: DKIM antispam standard can't stop spam

["Dude VanWinkle" <dudevanwinkle () gmail com>]

On 7/13/07, Valdis.Kletnieks () vt edu <Valdis.Kletnieks () vt edu> wrote:
> On Fri, 13 Jul 2007 15:23:45 EDT, Dude VanWinkle said:
> > As long as people who care will have the ability to add to the success
> > of the system ,while it still accomidates those who lack the technical
> > skills or desire, I am all for it. Even though it will be left up to
> > the hostmaster of each domain, I think the fiduciary issues related to
> > spam (bandwidth, storage backing up that storage, lost employee
> > productivity, having to teach monkeys about quarantining, etc) will
> > convince most to join in.
>
> The problem with most anti-spam "solutions" (including both SPF and DKIM) is
> that the cost of deployment gets paid by one place, but the benefits reaped by
> somebody else.

So if you have 1,000,000 spam a day at 50KB  per spam and you have to
pay for the bandwidth, backing them up to tape and disk, added to the
expansion of email storage (one of the most expensive types IMO) It
still isnt worth it to list every server who can send out mail from
your domain? Maybe the returns dont match the investment, I dont have
the numbers to run the math..


> So if we deploy SPF, *we* pay that deployment cost (which in
> our case is non-trivial, as there's a fair number of departmental mail servers
> and even a few off-campus ones we needed to find and allow for).  However,
> we don't see any direct benefit - the sites that *query* the DNS for our SPF
> record are the ones who benefit.  Similarly, AOL or Yahoo don't benefit by
> publishing their SPF - *we* do if we choose to check it.

AOL and Yahoo probably have to most incentive for reducing spam.
Consider how much of storage their storage is dedicated to spam? 10%?
40%? How much of their bandwidth is used for the same? Thats a lot of
profit to be harvested for just doing the right thing.

I would bet you could hire 1 person that could SPF aol.com by
themselves and then just fire them after the finish ;-) lol jk etc



> (Then there's the cost of deploying code to *check* DKIM, which is particularly
> heavyweight.  SPF and various DNS blocklists, you can decide to '552 Fuck Off'
> a message before you even see the RCPT TO/DATA (SPF you can 552 after the
> MAIL FROM, a DNS blocklist you can 552 even at EHLO).  For DKIM, you need
> to actually get into the DATA step and see the headers and then 552 after the
> final '.'.  This becomes significant if you're dealing with several million
> pieces of e-mail a day.....)

Thats what worries me, you dont wanna have to deploy new code to SMTP,
putting validation before or after seems more sane. but whatever works
is cool i guess..

> This assymetric cost leads to the "chicken.. and egg" issue that we see often -
> nobody wants to deploy early because it doesn't get them anything, and nobody
> benefits until a reasonable fraction deploy.


Eggs came before chickens. Fish laid eggs and they were several
hundred million years older than chickens.. ;-)

-JP
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.