Re: Spammers Skirt IP Authentication Attempts

[Douglas Otis <dotis () mail-abuse org>]

On Wed, 2004-09-08 at 09:59, Paul Vixie wrote:
> vgill () vijaygill com (vijay gill) writes:
>
> > ...  That means that if I do get a mail purporting to be from citi from
> > randomgibberish, I can junk it without hesitation.
>
> agreed, that is what it means.
>
> however, and this is the important part so everybody please pay attention,
> if you can junk something "without hesitation," then spammers will stop
> sending that kind of "something."  they make their money on clickthroughs,
> final sales, and referrals, which translates to one thing and one thing
> only: "volume."  if the way to keep their volume up means "put SPF metadata
> in for the domains they use" or even just "stop forging mail from domains
> that have SPF metadata" then that is exactly what they will do.  guaranteed.
>
> there's a bet here.  you could bet that by closing off this avenue, SPF will
> force spammers to use other methods that are more easily detected/filtered,
> and that if you play this cat&mouse game long enough, it will drive the cost
> of spam so high (or drive the volume benefit so low) that it'll just die out.
>
> i lost that bet during my MAPS years.  your mileage may vary, but to me, SPF
> is just a way to rearrange the deck chairs on the Titanic.  we won't have
> decent interpersonal batch digital communications again before whitelists;
> everything we do in the mean time is just a way to prove that to the public
> so they'll be willing to live with the high cost of fully distributing trust.

The first step along this path is to ensure a means of obtaining a name
that can be used to establish a history of use.  Neither SPF or
Sender-ID provides a domain name without making unverifiable assumptions
of the mail channel integrity.  The CSV proposal, now in the MARID
group, provides a means of obtaining both an authenticated and
authorized name useful for establishing a history without the high
overhead associated with tracking addresses.

SPF and Sender-ID expect the recipient to expend perhaps hundreds of DNS
queries and execute complex macros that are seemingly designed to hide
the scope of the outbound SMTP addresses, where a single wildcard record
and random sub-domains will devour the recipient's resolver.  

Neither Sender-ID nor SPF stop the citibank.com spoofing, as the last
header checked is the RFC2822 From.  Spoofers only need to employ a few
simple tricks, and the phishing continues, but now with a receiving MTA
burning more than twice the network and iron.  Sender-ID seems to be a
means of injecting Microsoft IPR and to place a foot in the door to
allow never-ending feature creep and DNS bloat.

-Doug