ietf-mxcomp
[Top] [All Lists]

Re: CSV (Crocker's draft) good! (evaluation, big suggestion)

2004-05-07 18:47:10


On 5/7/2004 4:35 PM, Greg Connor sent forth electrons to convey:


--Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote:

On 5/6/2004 9:31 PM, Greg Connor sent forth electrons to convey:


--Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote:


Perhaps I'm slow, but I look at this thread and I can't tell whether
most
folks like CSV+NBB.  Greg C seems to like it. Compared to SPF, it's
orders of magnitude less effort to adopt.  It doesn't provide
accountability as granular as SPF, which is partly why it is easier to
adopt.



What?  No I don't. :)


"That's an interesting idea. I like it. However ..." began your comment
on CSV+NBB.



Sorry for the conflicting messages there... I meant to say I like the idea (your idea, not Dave's) but I don't care much for the proposal (because it involves CSV)



I think the point I was trying to make was that SPF does what CSV does
and more,


Aye, it does what CSV does, and more: it requires that some two orders of
magnitude more systems be touched in order to implement it, as I
explained in my original post.  Not a good thing.



Right. SPF requires a lot more work and a lot more forethought. But, most participants on the list have said that they want MAIL FROM and From:/Sender: to be protected, which CSV fails to do.

Yes, MAIL FROM protection is something CSV fails to protect. And that's significant, because if it's protected, bounces will soon no longer be much of a problem. But with NBB, CSV provides this benefit, which is the main motivation for protecting MAIL FROM. But SPF fails to protect the domain in From: too. And if we say that's ok, it protects From/Sender/Resent*, then we're saying SPF doesn't protect From 'till everyone upgrades to mail clients that support this. Now we're talking what? Easily 2 orders of magniturde more work than CSV. CSV+NBB could require new mail clients display the HELO, and accomplish roughly the same thing (ok, that's a bit half-baked...). Not to mention that I explained how CSV does provide a way to protect From: (through incenting blacklist submission).


To me, CSV is like dropping your keys in the parking lot, and then going back to the lobby to look for them because the light is better there. Sure, it may be easier, but it totally misses the point. I can't in good faith count CSV as a real LMAP proposal.

It's a good joke, but I don't think it't a fair analogy. My original post was all about how and why CSV accomplishes a lot more than is immediately apparrent.


without having to create SRV records.


I advocated CSV switch to use TXT records in my second post to this
thread! And you didn't say a thing about SRV records in that post!



Actually, I failed to mention it mostly because I agree with you :) SRV records are clumsy and not ideal for what Dave wants to do.


...
http://wiki.fastmail.fm/wiki/index.php/AntiSpamOptionsMatrix


I will check those out. I think we have a week or more of discussion before people will be ready to agree on any features, though. Sigh :)


Maybe it being a wiki will make this less likely. In conclusion, SPF is a good idea; I'd give it a "+" in my ranking scheme. I used to rank it +++, but then I realized more fully how much work it'd be to adopt. I'm still convinced CSV+NBB does have a greater chance of accomplishing what's important.