----- Original Message -----
From: "Bart Schaefer" <schaefer(_at_)brasslantern(_dot_)com>
To: "ASRG" <asrg(_at_)ietf(_dot_)org>
Sent: Sunday, November 30, 2003 8:00 PM
Subject: Re: [Asrg] 0. General - Inquiry about CallerID Verification
} I fail to see how. I would love to see an example.
As my original example doesn't seem to have gotten the point across, I'll
try it another way.
Bart, I did not fail to see what you were saying nor fail to see the
possibility. What I fail to see is how this is any different from any
other malicious system performing the same attack where there is ANY kind of
validation.
This is more of a scalarbility issue where there are solutions.
One possibility is use a client/server/farm framework, couples with IP
analytics. In short, a centralized tracking system. But this applies to
EVERYTHING. Thats my point.
let me summarize your thinking:
W = 10,000 sites with Callerid Verfication (WCSAP)
Q = 10,000 sites with Callerid Verfication (other)
V = 3rd party site.
X = Spammer spoofing V site
X sends 1000 messages to each of the sites in W, forging V's domain in
the MAIL FROM:. What happens to V's MX host?
Assuming V will fail to validate the return path provided by X, WCSAP will
track X IP address vs domain to stop any further validation against the V's
MX host.
If X uses a diifferent connecting IPs, this also can also be sensed.
Next X sends 1000 messages to each of the sites in Q, forging random
domains from W. What happens?
Same as above.
In the victim V case, an innocent third party has been DDoS'd by the
servers in set W.
Note if its not tracked.
In the Q vs. W case, what stops all the systems involved from deadlocking,
as each site in W tries to caller-ID the non-empty MAIL FROM: generated by
the servers in Q, which then try to caller-ID the non-empty MAIL FROM:
generated by the servers in W, and so on around again?
See commment above.
} Retries are part of the functional specification of SMTP systems.
That's not what I mean.
How is it a non-issue _for the system that is issuing the 421 response_
that it has become so busy that it is _necessary_ for it to issue such
response?
Like everything else, it can be attacked or consume for other reasons that a
WCSAP like system. The server has to be prepared for it. If not, then DNS
load balancing is required by the site.
Again, its not scalability question is what you are really asking, and from
that point of view, I fully agree. It doesn't have be because of a SPAMMER.
It could be a regular system sending "lots of mail" and even in this case,
tracking has be done to address redundancy.
Why is it a non-issue that timely receipt of email by your servers has
been interrupted, even if temporarily?
Again, it a non-issue because it CAN happen anyway and lets remember, this
is ONLY an issue for non-compliant systems and for ghost systems. So if
the concept is WIDELY deployed, senders and receivers will be probably
configured and spammers will be reduced to a bare minimum.
} Not an issue.
Again, why not?
Already stated above.
All challenge systems are highly effective when deployed in isolation.
(As a side note, I would not catalogized this as a challenge system.
Technically, challenge concepts are dynamic in nature, where it is often
initiated by the server upon contact (or the initial stages) with a client
matching the challenge.)
The troubles begin when you consider what happens if they become widely
distributed.
Than its a scalability issue and it applies across the aboard.
Again, lets remember the main point here. The SMTP state point, MAIL FROM:
is calling a black box validation function:
MAIL FROM: -----> BLACKBOX VALIDATION.
WCSAP is just one method to do this. It is highly effective, but present
scalibility/loading issues that need to be incorporated in its design. As
a blackbox, design a better MAIL FROM: validation concept, and it is easily
replaced. No change to our SMTP server. So from my point of view our SMTP
server is design to address a strong MAIL FROM validation concept. That is
ALL I am proposing YAKOV et al to focus on. The PROTOCOL! Then we can come
up with solutions and even then, it is not going to be 1 single solution,
unless it something that really works 100% and addresses scalability issues.
With WCSAP (Source Code provided with our Compiler/SDK plus pack),
developers or companies can CHANGE it to comform to what they want it to do.
---
Hector Santos, CTO
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