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

Thu Aug 12 22:32:24 UTC 2004

On Thu, 2004-08-12 at 14:43, Scott Francis wrote:
> 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.

There is a proposal that should interest you.  It is called Bounce Tag
Address Validation By Dave Crocker.

http://www.brandenburg.com/specifications/draft-crocker-marid-batv-00-06dc.html

This proposal is now in the IETF MASS WG.  It does not require everyone
to use your records to get rid of spoofed bounced return paths.  They
are working on a public key version of this to allow the spoof to be
dropped before being bounced.

> 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.

Keep in mind, the IETF MARID WG dropped SPF in favor of Sender-ID. 
Sender-ID does not provide any spoof bounce relief as it does not
examine the MAIL FROM.  It also adds an onerous, and likely to be
expensive with respect to customer support, limitation on the RFC2822
>From header.

> > 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.

That will change with Sender-ID.  Everyone will complain when everything
breaks.

> > 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 value in SPF has been its utility in setting up white-lists.  BATV
should do a much better job for stopping spoofed bounces, however.  

> 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.

The CSV proposal will go to Last Call in early October.  This repairs
the inability to authenticate the EHLO domain.  It also indicates the
SMTP client is authorized by the domain, in much the same way SPF
attempted with the MAIL FROM parameter.  The expectation is that with
name based accreditations, the vetting process can be faster and there
is a history that can spot the newbie servers to allow a go slow mode as
example.  Combine this with BATV and this should have a significant
impact upon spam moving forward.  The advantage would be obtaining a
Name Accreditation as a means to avoid the filter slough.  

> 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?

Unlike SPF, and especially Sender-ID, the overhead for CSV is nil.  It
simply replaces an A record lookup with a CSV-CSA record lookup. 

-Doug