ietf-mxcomp
[Top] [All Lists]

Re: Rough consensus reached. Let's move on.

2004-04-16 10:06:26

On 4/15/04 1:19 PM, wayne sent forth electrons to convey:

In <407ECAFE(_dot_)60106(_at_)elvey(_dot_)com> Matthew Elvey 
<matthew(_at_)elvey(_dot_)com> writes:

There hasn't been any consensus movement toward or strong argument for
elimination of 1, 2, or 3. Agreed?
ARRGH! This wasn't a requst to rehash weak arguments on either side that have already been made.
But, that rehashing just proves the position I took in the above quote.
It's nice to see that several people posted that they agree with me. Stay behind if you want.

I think 2822 validation is a much harder problem and we will benefit from some early success.

The first half of that statment is fact free, and the second half is absolutely backwards. People expect the standard we come up with to substantially reduce spam flows (as recent press has confirmed). If it doesn't, and IMO there's a big risk it won't, the result is LESS credibility than we have now, not more! We've got <2822 validation is too hard to tackle> (above quote) and Andy saying it's not complex (both saying it's a bad choice). One of those arguments has to be wrong, and developing a more detailed plan (i.e. code, as my thread-starting post suggested) for using MARID info bringing together ideas from several folks already presented. In particular, I am confident that the assertions needed to support even the most baroque of possible solutions are not complicated. And that's all we're actually specifying: the assertions. It is unscientific nonsense to say that adding an assertion increases the complexity of the assertions exponentially. I'd say for certain O(n) <= n, WELL BELOW not EXPONENTIAL. Once you're making the effort to create and install a MARID record in DNS, adding another assertion is trivial, so it's actually the case that O(n) = 1 !!! What's true is the complexity of the analysis code grows rapidly, but for its execution time, O(n) is between 1 and n, because of shortcuts that will be common. I know this because I wrote some pseudocode to handle 2821+2822, and that's what I found. (For those not in the know: O(n) is a computer science way of annotating/describing the growth in resource demand of an algorithm.) (err - just saw PHB beat me to the punch with this argument, so here it is again, described differently).


Well 3) was the RFC2822 stuff.  The more I think about it and the more
I learn about the current state of the propsals in that area, the more
confident I become in saying that there isn't a clear solution.

That just proves my point. If that's a "strong argument for elimination", I'm an 8 legged chicken. There has been valid criticism of 2822 stuff, but nothing like a strong argument for elimination. There has been valid criticism of 2821 stuff, but nothing like a strong argument for elimination.

2822 checks are NOT too complicated, or much more complicated than 2821 checks. What's the time it'll take this to be hammered out compared to the time to get MARID broadly deployed? Nothing.

Apropos Andy Newton's comments: this is inane. The IETF is NOT about an anonymous group dictating how things are gonna be with public discussion being nothing but a rubber stamp. I feel like a spam beneficiary is setting the agenda behind the scenes! It seems like we're working hard to AVOID coming up with a really good solution. We've already seen what happens when folks implement (what 20/20 hindsight shows were) seriously flawed antispam schemes, such as C/R, banning open relays, etc. It seems like some folks are content to create another JAHCASS (JustAnotherHalfCookedAnti-SpamSolution?) Officer Andy is wrong. It is absolutely not forbidden for us to endorse a scheme that implies a suggested tighenting up on what is allowed in SMTP. I would remind everyone that most major ISPs are very tolerant of spammers, and that some of this spam benefiting contingent has probably, based on the odds, found representation within the IETF, so we must be careful. There is certainly mainsleaze among us. The IETF is whoever want to participate and we're not infallible; heck, SPF was published as an I-D in violation of the IETF's own policies.

And what's with complaints that 1-8 aren't in scope or aren't obtainable? I explicitly said that some weren't! Read, people!

OT: Microsoft folks: Your continued failure to identify your claimed IP is contributing to the sidelining of your ideas. Please remedy the situation ASAP.