On May 26, 2004, at 8:32 PM, Seth Goodman wrote:
I take that to mean that one client was maliciously knocked off the
net by a
concerted attack by Verizon. I take the second instance as meaning
that AOL
intentionally targeted that server and saturated its network bandwidth
to
the point where it had no effective internet connectivity left. If,
instead, you are saying that the first site got more CBV's than it
wanted,
the second site received lots of forged bounce spam and both were very
annoyed, that's life on the uncontrolled internet, not a DoS attack.
No. It is pretty clear that Verizon and AOL wouldn't intentionally do
that. They were used by a 3rd party as a weapon do that. And yes the
services were taken offline in both cases due to service saturation.
"more than they wanted" and "lots of forged bounce spam"? If either of
those occupy enough of my resources to degrade my services and thus
deny service to any clients, then yes it is absolutely a denial of
service attack. Denial of Service attacks do not need to completely
saturate anything, they just need to affect them and denies legitimate
traffic (not necessarily *all* legitimate traffic).
http://www.cert.org/tech_tips/denial_of_service.html
Here I'd like to ask you a question. Isn't it possible to engineer an
MTA
so that a CBV is not as burdensome as you describe? Perhaps it isn't,
but
here's the basis for my question. You can't tell after RCPT TO:
whether the
SMTP-client is doing a CBV or sending a DSN. If the response to RCPT
TO: is
a 250, a CBV request will terminate shortly thereafter but a DSN will
go on
to a DATA command. Would it be possible to delay the evaluation of the
user's quota and anything else besides local address validity until
after
you get the DATA command? If for some reason the account cannot
accept the
DSN, isn't it possible to respond to the DATA command with a 503 or
554 to
terminate the transaction instead of a 354?
It's very awkward with multi recipient mail. It can be done with
single recipient mail, only your don't have forward knowledge of that.
The amusing thing here is that I don't particularly like the idea of
CBV's,
either. If you can think of a more efficient way to validate MAIL
FROM:
after an arbitrary number of forwards, I'd be very interested. I
would much
rather that a DNS server could provide the validation, since it is
based on
UDP, but that doesn't seem to be terribly feasible. A full PKI system
is
far more expensive than CBV's, and shouldn't be necessary to solve this
particular problem. Looking at the big picture, I feel that a
cooperative
model, which may include CBV's (or some other mechanism), gets us all
further than a system where we never "bother" each other and continue
to
suffer individually. I'm sure that game theory has something to offer
concerning this scenario, but unfortunately, I'm unqualified to
comment.
I'm practical person too.
Full PKI isn't really that expensive and the beauty of it is that is
doesn't victimize anyone. As for signing and verification, the cost
for reasonable performance is really minimal (as in most people won't
need hardware acceleration). With a $1000 crypto card in a server you
can do 4,000 or so signs or validates per second. 4,000
messages/second is above our test lab results for Ecelerity. We can
really only push about 2000 message/second over SMTP in our lab (about
7.2 million message/hour). As people are striving for these lab
results in real life and 300 message/second on a single server seems to
satisfy most people with performance concerns, PKI just doesn't seem
that intimidating.
We'll see how the DomainKeys stuff plays out, that stuff looks exciting
too.
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
// Ecelerity: fastest MTA on Earth