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.
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: User experience, (continued)
- Re: User experience, Doug Royer
- Re: User experience; RHSBLs; Strong From: check seems possible, Matthew Elvey
- Rough consensus reached. Let's move on., Matthew Elvey
- Re: Rough consensus reached. Let's move on., Marshall Rose
- Re: Rough consensus reached. Let's move on., wayne
- Re: Rough consensus reached. Let's move on., Jon Kyme
- Re: Rough consensus reached. Let's move on., Marshall Rose
- Re: Rough consensus reached. Let's move on., Jon Kyme
- Re: Rough consensus reached. Let's move on., Andrew Newton
- Re: Rough consensus reached. Let's move on., Jon Kyme
- Re: Rough consensus reached. Let's move on.,
Matthew Elvey <=
- Re: Rough consensus reached. Let's move on., Marshall Rose
- Re: Rough consensus reached. Let's move on., Alan DeKok
- Re: Rough consensus reached. Let's move on., Matthew Elvey
- Re: Rough consensus reached. Let's move on., Arnt Gulbrandsen
- Re: Rough consensus reached. Let's move on., Greg Connor
- Re: Rough consensus reached. Let's move on., Tony Finch
- Re: Rough consensus reached. Let's move on., Markus Stumpf
- Re: User experience, Alan DeKok
RE: User experience, Hallam-Baker, Phillip
RE: User experience, Harry Katz
|
|
|