----- Original Message -----
From: "Bart Schaefer" <schaefer(_at_)brasslantern(_dot_)com>
To: "ASRG" <asrg(_at_)ietf(_dot_)org>
Sent: Sunday, November 30, 2003 12:03 PM
Subject: Re: [Asrg] 0. General - Inquiry about CallerID Verification
} This is already controlled by server access and availability.
You're missing the point.
You might believe it's a non-issue for you, but that doesn't make it a
non-issue for everyone who might become a victim of it. Recommending an
approach such as your caller-ID technique is irresponsible, because it
can lead to indirect abuse of innocent third parties.
I fail to see how. I would love to see an example.
} This is already controlled by server access and availability. The
number
} of receiver threads are definable by the sysop with a server 421
greeting
} response of:
}
} 421 domain, Service not available. Try again later
How is this a non-issue?
Retries are part of the functional specification of SMTP systems. JAVA
beans, scripts with 1 shot approaches are asking for trouble, with or
without this.
ALL of your mail is going to stop flowing with
this error until such time as the flood of caller-ID connections stops.
No, its not. Again, I fail to see this. I have WCSAP running for nearly
5-6 days now with very little issues that is being worked out.
And assuming the hypothetical ISP in the example does wait and try again,
You can't design software on the assumption that SMTP systems will not be
following specifications. You will go nuts otherwise.
you'll have those interruptions repeatedly until all the forged messages
drain out of the ISP's queues.
Not an issue.
This leads to a further question (of academic interest only, really): You
have said that your system returns a 4xx to the sender when the caller-ID
callback is unable to connect. What does it do when the callback gets a
4xx response itself?
It returns the same thing back.
Look, functionality is a IDEAL solution.
The implementation has to be worked out. One implemention (WCSAP) is to
implement it within the confines of the SMTP system in theory and in
practice.
The goal (at least for us) is to functionally engineer a "WCSAP" so that it
fits into our SMTP server, so that it does return a TRUE negative or TRUE
positive. The day a more reliable "CallerID Verification" is worked out,
be it some other protocol, or lookup, etc, we simply substitute it. I
don't like WCSAP for one reason only, its OVERHEAD, but functionality, its
is a great!
I am going to make available the logs from WCSAP. I think you will find
them interesting. There are questionable issues that need manual checks.
There are also VERY interesting behaviors (as we learn about YAHOO delayed
validation).
But BY FAR, with EMPERICAL DATA on hand, that this is the best METHOD out
there to combat illegal spoofing by spammers. I have provided 6 months of
emperical data of state point validations.
with these two alone:
strict HELO/EHLO format checking
MAIL FROM: validation
you will eliminate a large percentage of the spoofing spammers.
If real operations did not show this, we wouldn't be doing this.
----
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