Greg,
GC> I'm not exactly pleased to see my post carved up, with a number of 1-3 line
GC> responses added for every 1-3 lines I wrote. I feel it is a style that
GC> encourages fighting, bickering, and disagreement rather than mutual
GC> understanding and consensus-building.
It is a well-established style, designed to cite precisely the text
being responded to, in the style of a dialogue, and without carrying
unnecessary baggage from the quoted message. It presumes that folks
have access to the original, so it need not worry about the 'flow' of
the message. In this case, I felt that responding to the details of
your note was appropriate.
GC> So, to be clear, I am suggesting that this assumption is not valid or
GC> useful. I think the reputation of the MTA is often interesting, but
GC> certainly not enough in itself to judge the quality of the mail.
You might want to discuss that view with the substantial fraction of
the anti-spam listing services that do not share your view.
GC> But,
GC> after reading your message I am starting to think that you don't believe
GC> this assumption either, that there are only "good" and "bad" MTAs.
Discussion will probably be more productive if we refrain from
guessing each other's beliefs.
GC> In that
GC> case, this disagreement is not directed at you, but at other CSV supporters
GC> (Matthew and Doug) who have been suggesting that checking HELO against a
GC> reputation is pretty much all you need
None of the CSV folk have made any statement like that.
GC> and other proposals that check other
GC> identities are worthless, doomed to failure, or both.
None of the CSV folks have made any statement like that.
GC> 1. I want to stop spam too, and I think stopping forgery is a necessary
GC> but sufficient step.
That has not been the typical view of SPF proponents. Nor does it
have any objective, analytical basis.
Spam does not require forging. Forging is simply a convenient hack,
so it is used... for now. Spammers have shown an impressive degree of
adaptability. Take away one convenient hack and they find others.
GC> apparently-from and bouncing-to our own domains, a MAILFROM/PRA check
is GC> going to be required.
Some sort of rfc2822 author/sender accredition is going to be
required... in some cases.
GC> Agreed :)
I hope you, and everyone else, understand that I said something
significantly different from what you said.
GC> Mechanically, CSV and SPF are both capable of checking HELO.
Mechanically, CSV and SPF are both fruit. But let me tell you, you do
not want to think about or use durian the same way you think about and
use oranges.
However, your statement highlights a deeper problem in most of the
efforts to discuss CSV and SPF differences: Such efforts are almost
entirely tied to mechanical and syntactic issues and do not focus on
underlying concepts.
GC> Right... That actuall IS what I mean here -- I mean to separate the
GC> mechanics of each proposal from the underlying concepts. The assertion I
GC> was trying to test is whether the mechanism SPF uses to test PRA, MAIL FROM
GC> and HELO is capable of doing the same things the CSV mechanism does.
Marshall Rose recently published an article about helicopers and
submarines in an ACM periodical. If there is an online citation to
it, I suggest you take a look at the point it makes.
GC> Speaking only of the
GC> *mechanism* I don't see that SRV records have an inherent advantage over
GC> TXT records, or that the underlying concepts of CSV depend on SRV records.
I think Douglas has been doing quite a good job of speaking to that
point. A careful review of his postings on that matter might be
helpful.
CSV and SPF are fundamentally different pardigms.
CSV vets an MTA's traffic.
SPF vets an RFC2822 author/sender's message.
SPF:
Per-message MTA path validation, based on Author/Sender
authorization and accreditations.
CSV:
MTA traffic validation, based on MTA operator authorization and
accreditation.
SPF vets an MTA's sending a single message. It accredits the MTA
based on the RFC2822 author/sender. While introducing a
path-dependency into the mechanism, it simply defers the hard
question, namely accrediting the author/sender.
CSV vets an entire MTA session. It accredits the MTA based on the
operator of that MTA.
GC> I don't really agree that CSV and SPF are fundamentally different
GC> paradigms.
Do you disagree with any of the summaries about the two that I list,
above?
If you do, then please explain.
GC> I think of SPF not as a great idea, but as a collection of great ideas.
Actually, what you then proceeded to describe was a bunch of
mechanisms.
What I am rather pointedly trying to do is conduct a discussion based
on the concepts and information-theorectic aspects of the two services.
GC> The point of this exercise is to separate the "mechanism" carrying the
GC> message from the content and meaning of the message itself.
That might be *your* goal, but *mine* is to make sure we all are in
synch about the differences in the NATURE of the two services, before
haggling over the details of the mechanisms.
GC> I will note also that despite disparagement pointed at the "unknown" mode
GC> of SPF, CSV also has a de-facto "unknown" mode - you can just choose not to
GC> publish any records at all for that particular name.
There is a significant difference in cost between doing no work,
versus doing a bunch of administrative configuration and networking
querying and analysis of the responses, only to produce an unknown.
GC> I don't know why Matt and Doug chose to say over and over again how nasty
GC> and yucky and vulnerable SPF is,
Perhaps because they have some relevant operations experience with
complex configurations and the deliterious effects of functional
interactions for complex mechanisms.
GC> citing this as a reason why CSV is cool
GC> and wanted and necessary.
Actually, I read their notes as saying two separate things. One is
about the spiffiness of CSV. The other is criticism of SPF.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>