Re: So here it is one year later...
Douglas Otis <[email protected]> Tue, 01 Feb 2005 17:04:12 -0800
| Newsgroups | gmane.ietf.mxcomp |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 2005-02-01 at 16:42 -0500, Hector Santos wrote: > Is this a CANNED reply message? It sure reads like it. It sure feels like the same issues. > Look, CSV does not pass the test for consideration. That might > explain why no commercial vendor has implemented it. The goal for CSV is to reach consensus on a well considered design, run tests, and then attempt to pass muster with a standards effort before widely promoting it. Considering impacts upon existing infrastructure has been no small part of this process. It would seem proponents of SPF have concluded problems resulting from changes to the rules without record versioning is acceptable. Does it really matter the same view is held by the Sender-ID faction, as well as the SPF-Classic faction? The spf.org site makes it clear Sender-ID causes mail delivery problems. Schlitt's draft also makes it clear forwarded mail may be lost and "Tests against some other identity may also be used to override the test against the "MAIL FROM" identity." What other identity? Being this vague ensures there will never be a "chain of trust". This type of approach makes it impossible to judge, from the perspective of implementation, who is doing what. Forgive those that take a longer view. It seems SPF has already lost control over how these records are used. Breaking mail as a way to inflict change is not justified for a system that makes consumers rather than providers accountable. Lack of authenticating the message source, in the long run, may prove costly as these problem become apparent. > And we were not talking about MASS. We are talking about the fallacy of CSV > being immune to heterogeneous/mix policy topologies and lacks overhead > issues. You are wrong in both cases. You seem to be obsessing on having SPF replace the role of a responsible administrator. Alas, SPF can not be trusted to properly indicate the source of abuse. Please don't say this is not your concern, and that it is the victim's. > I think you are saying MASS solves these problems for CSV. The need to protect the sender's mailbox-domain can be safely provided by MASS. CSV never attempts to fulfill that role. CSV is the first protective phalanx for the network, based upon a name rather than an IP address. This could work in conjunction with a common name based reputation system. MASS will never offer protection for the network, whereas CSV can. SPF, with its high overhead, does not afford network protection advantages. > Well, that's a PAYLOAD solution so it doesn't address the heterogeneous/mix > policies and overhead issues at the SMTP level. So I believe you are > incorrect here as well. A minimal overhead at the SMTP level is definitely an advantage that CSV offers over SPF. The disagreement seems to be whether SPF provides greater benefit by excluding messages that do not comply to an expensive path registration. Forwarding is now defined as "illegitimate" and messages lost as a result of transparent interception at hotels and network kiosks is "acceptable" even though these are effective anti-spam deterrents. Will customers accept such problems and blame under the guise of defeating spam? -Doug