spf-discuss
[Top] [All Lists]

Role of SPF in fighting spam

2005-06-29 16:00:02
At 02:46 PM 6/29/2005 -0400, Scott Kitterman wrote:

>-----Original Message-----
>From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
>[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of David 
MacQuigg
>Sent: Wednesday, June 29, 2005 2:38 PM
>To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
>Subject: Re: [spf-discuss] Border Appliances
>
>
>At 10:27 PM 6/28/2005 -0700, Greg Connor wrote:
>
>>>> > This raises a serious question - If many domains use these "appliance
>>>> > boxes" as their border MTAs, how can we expect *any* IP
>authentication
>>>> > method to work?  Are we expecting these appliances to be replaced by
>>>> > general-purpose MTAs?  I assume there is no chance of modifying their
>>>> > proprietary software.
>>
>>Probably true that it's difficult or impossible to add after-market, but
>>if enough of their customers ask for it...
>>
>>In the early days of SPF, we can probably have a noticeable impact even
>>without getting 100% adoption in the field... I think we can have a
>>meaningful impact even at 10%.  All it takes is some of the big name
>>receivers -- maybe just a handful -- to start checking SPF and
>I'm betting
>>that spammers will start to avoid SPF-protected domains.  May not reduce
>>overall spam at first, but if domain owners see a decrease in forgery
>>activity, that's something, at least.
>
>Let's be careful not to over-sell SPF as anything more than a piece of the
>solution.  Without a domain-rating system coupled in, the best you can do
>is PASS a few well-known domains that authenticate, and maybe FAIL an even
>smaller number where the record says -all.  The vast majority will be
>"unknown" domains, and whether they authenticate or not, might even
>correlate the wrong way with probability of spam. i.e. spammers may be
>*more* likely to authenticate their dime-a-dozen names if nobody is
>checking reputation.
>
Your time on the CLEAR list is showing here.

Let's discuss only the issues at hand, and not question each others motives. I'm not pushing CSV or their domain-rating system.

SPF is not anti-spam, it's anti-forgery.  Stopping non-forged spam has
nothing to do with SPF.

Agree. I was reacting to Greg's "betting that spammers will start to avoid SPF-protected domains". We were talking specifically about spammers. The only thing I would change about your statement is I would say "Stopping non-forged spam is not the purpose of SPF." "nothing to do" would rule out "enable".

I can't speak for anyone else, but since I've published a -all record, the
number of bounce messages I've gotten due to forgery of my domain names has
gone to essentially zero (about one per week rather than dozens/hundreds per
day).  SPF works to do what it was designed to do.  Reputation has NOTHING
to do with it.

This is good news. It implies that spammers have notice your -all and are not using your domain as a bounce address. Still, it seems like getting rid of fake bounces is only getting rid of a minor annoyance. They can be rejected by other means just as well.

If someone as a separate project is building domain based reputation
assessments, great, but it sounds like something SPF could enable, but not
part of SPF.

Agree. "Enable" will come automatically. I'm still hoping for "collaborate with", or even just "facilitate".

>From an SPF perspective, as long as they don't forge MY domain names, SPF
has done it's job.

"I'm betting that spammers will start to avoid SPF-protected domains." isn't
hype - it's what has happened.  Frank has reported similar results.

As I understand it, they are not using SPF-protected domain names in their return paths, but they are still sending spam to those domains.

Let's be careful not to spread FUD here either.

I don't see what you are calling FUD.  Please clarify.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *



<Prev in Thread] Current Thread [Next in Thread>