On Thu, Jan 22, 2004 at 02:08:18AM -0500, Marc Alaia asserted:
Seriously, though, have you considered to what degree this list is skewed
toward ISP's? Yes, ISP's are a significant player in this arena, but NOT
THE ONLY ONE. Companies such as Paypal, Citibank, Bank of America,
Merrill-Lynch etc., have much more riding on this than the relative bandwith
consumption. As a corporate user, I have a surplus of bandwith. I have
sized my pipe within the constraints of cost and performance. I have a 768K
SDSL line that is probably at 30-50% utilization on a given day (during
business hours). Probably under 5% off-hours. My bandwith-cost of spam is
ZERO, as is my CPU-cost. If I eliminated spam, I would not save any money
at all. Nearly all cost-analyses of spam refer to the costs that
corporations incur and nearly every one that I have read practically
dismisses the costs of bandwith and CPU time. The biggest cost to
corporations is face time in dealing with spam.
The benefit is skewed toward ISP's only in the sense that we are affected
the most by the consequence of not doing something. Even corporate users
could derive some benefit from spf. Just not of the same magnatude as ISP's.
Ok, what are the negative effects of the spf proposal?
1 - You have to publish a single record per host per domain and accept
responsibility for your domain's traffic when originating from those hosts.
2 - You may reject mail from hosts who are unable or unwilling to do the above.
3 - Hank the spammer can't Joe job anymore. Unemployment rises, etc...
On the positive side?
1 - You may or may not use the spf record as a determining factor. Its up to
you.
2 - If you query for the spf record and it does not exist, you save either
bandwidth or face time. Either way, support costs drop.
3 - If you publish an spf record and the rest of the world follows, then at
some point, Joe jobs disappear. Reducing potential support costs should some
spammer ever attempt to forge your domain.
4 - Trojans living on client PC's would be unable to spread their payload.
While I'm sure there are plenty of arguments for both sides. I honestly don't
see the business case for not publishing the spf record. Its a simple dns
change that costs nothing unless you retool to take advantage on the receive
side.
I'd guess that spam-caused bandwith utilization is not the major portion of
Yahoo's Internet connection charges, let alone their Cost of Revenues.
If a simple idea saves me the constant aggravation on spam fallout, I'm all
over it. In a corporate world, it'd be a hard sell to tell the shareholders
'well, we could have reduced our support budget by x% if we had adopted it,
but we didn't'.
I am highly dedicated to SPF and desperately want to see it succeed. I am
just asking to be heard. Again, althought there may be a lot of ISP-related
parties on this list and therefore participants in the development of the
protocol, please consider the relative cost of the excess bandwith to ALL
parties. You (the ISP's and especially the forwarders such as pobox.com)
are the MOST SEVERLY affected group in this matter--nobody comes even close.
Don't let it cloud the discussion of how SPF fits in with overall anti-spam
efforts. As I have stated before and continue to believe, accepting the
message and processing it afterward has its benefits....
Not that you need my permission, but continue to speak your mind.
If you derive benefit from accepting messages that violate the proposed rfc,
then have fun. Make lots of money. rfc isn't law.
This just looks like a system with no downside unless you have reason to
forge headers.
--
Bob Greene
Public key available at
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC9C7841C
Or, you can just pull my finger
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡