On Thu, 2004-08-12 at 14:43, Scott Francis wrote:
On Thu, Aug 12, 2004 at 12:17:47AM -0700, dhc2@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.h... 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