Hi Peter
----- Original Message -----
From: "Peter J. Holzer" <hjp-asrg(_at_)hjp(_dot_)at>
To: "ASRG" <asrg(_at_)ietf(_dot_)org>
Sent: Sunday, November 30, 2003 4:04 PM
Subject: Re: [Asrg] 0. General - Inquiry about CallerID Verification
I fail to see how. I would love to see an example.
He already gave one.
To reiterate:
No difference from any other unhandled malicious attack. You don't need
this method for something that is intent on crashing your system. Of
course, you don't want it to begin on its own :-)
Of course this is not a new problem.
Thank you. :-)
After 5-6 days on a single site it seems awfully optimistic to me when
you say "we haven't been DDoSed yet, so it will never happen".
I would multiply this with about 10+ alpha/beta testers. I think it
significant at this preliminary level and with my vast engineering
experience in analyzing and solving problems, I don't currently see
anything better that works today within the confines of the current
specification.
We are going gamma with our new Product Updates this week. I might not
include WCSAP in this stage now. I need to work on it more - make it more
robust, faster and smarter. The YAHOO delayed validation needs to be
worked out or NOT. Hey, its only a STEP in the total state machine
validation systems. If can just say "Let him thru," and go the next step.
You can't design software on the assumption that SMTP systems will not be
following specifications.
You should. Because some systems out there won't follow specifications.
and I have dealt with broken software all the time. It par for the course
when you are in business serving thousands of customers. You might make
exceptions or workarounds for legacy situations or to deal with a broken BIG
GORILLA software. However, it is exception to the rule, not the norm. You
don't design software based on software NOT following specs. For one thing,
you don't know what is broken or could be broken. I know of no
specification that outlines or exposes a spec and then adds:
"If the client doesn't follow this, then you should work out the
problem with the client vendor"
Although, it will probably end up that way from a support standpoint when
you do cross that bridge. But you don't design software with this
assumption. The spec might say:
"If the client doesn't follow this step , then you should break
the connection"
"If the client doesn't follow this step , then you should go to
step 3"
but then this is a expected FUNCTIONAL design. :-)
You don't have to provide service to those systems (although your
customers may have different opinions about that),
Right. As with most things, it is usually customer driven. I am a firm
believer of pareto's principle.
but when designing the software you must consider what happens if the
the other breaks the > rules.
But again, you don't design your software this way based on a well design
specification. Fallbacks or sanity checks is something different, time
engineered situations evolved, workarounds, are different matters
altogether. It does make the difference from vendor to vendor. :-)
You will go nuts otherwise.
That's always a possibility ;-)
I'm already there <g>
---
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg