isn't "...isn't perfect, but it's something now"

Scott Francis darkuncle at darkuncle.net
Thu Aug 12 21:43:35 UTC 2004


On Thu, Aug 12, 2004 at 12:17:47AM -0700, dhc2 at dcrocker.net said:
> 
> Folks,
> 
> EBD> ...  SPF isn't
> EBD> perfect, but it's something now, and IMHO probably better than
> 
> This is a very popular view these days.
> 
> However there are some fundamental problems with it:
> 
> 1. It mistakes activity for progress.
> 
> 2. It ignores opportunity cost, diverting energies to efforts that are
> likely to have no effect on spam rather than allocating those resources
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> to basic improvement in the service.

I can't speak for anybody's network but my own ... but if everybody out there
was merely using my published SPF records to reject forgeries, it would cut
the amount of bogus SMTP traffic coming into my network by probably a third.
Bounces from forgeries are rapidly becoming a significant problem for regular
networks, where they used to mainly be a concern of large providers - I don't
get many forgeries claiming to be from {hotmail.com,yahoo.com,aol.com,etc.}
anymore.

Cutting bogus traffic by a third is not a huge amount, but certainly
non-trivial, IMO. Worth the effort of deployment? That probably depends on
your network's size, traffic makeup and architecture (technical and social).

> 3. It ignores the difficulties with administration and operation of the
> mechanism, as it scales, such as its Procrustean limitation of usage
> scenarios that are reasonably supported.

that is definitely a sticking point with anti-forgery proposals, I will
agree.

> 4. It treats a short-term mechanism as if it had long-term benefit; yet
> modification of a global infrastructure is always and only subject to
> long-term processes.

The problem with long-term solutions is that they require long-term
development. At the rate the spam epidemic has been growing, if we wait
until long-term solutions are ready before taking any action at a global
level, there may not be much of an SMTP architecture left to save. Maybe I'm
being overly dramatic ... maybe not. I suppose it depends on how much the
userbase is willing to put up with. Maybe they're more willing to put up with
the problem than with any of the proposed temporary measures (like SPF).
Maybe the average user couldn't care less about things like SPF, because
he/she is just using whatever setup his/her ISP set up, and all the
complaining is coming from a small segment of the technically clued. I don't
know.

> If SPF is wonderful, it had better satisfy a higher criterion than that
> it "isn't perfect, but it's something now".

It works very well for me - but my personal network is small and not
particularly complex. Obviously, mileage varies greatly by operator and
network. I don't think it's reasonable to dismiss the solution out of hand,
however, just because it doesn't meet the needs of _all_ networks. (Although
a solution that's only implemented by a few isn't much of a solution, unless
those few are Microsoft and the top 5 residential ISPs ...)

The one thing that seems certain is that if we wait until a solution appears
that works on all networks, and is supported by all players, and actually
fixes the problem ... well, there will be some unusually cold weather in a
very warm place when such a solution is announced, I suspect.

Doesn't it seem reasonable to employ some temporary stop-gap measures in the
short term, while waiting on permanent solutions to present themselves?
Technical progress isn't entirely a zero-sum game - work on temporary
measures like SPF does not necessarily preclude work on permanent solutions,
does it?

At any rate, this discussion is probably better taken up elsewhere (and I'm
sure the points on both sides have already been beaten to death.)

respectfully,
-- 
       Scott Francis | darkuncle(at)darkuncle(dot)net | 0x5537F527
<CaffeineHead> We have enough youth. What we need is a fountain of smart.
-- http://bash.org/?70562
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20040812/9df0a912/attachment.sig>


More information about the NANOG mailing list