----- Original Message -----
From: "Bart Schaefer" <schaefer(_at_)brasslantern(_dot_)com>
To: <asrg(_at_)ietf(_dot_)org>
} I already proved that it works.
You've proved that spammers use garbage envelope sender addresses. We
already knew that.
Then why aren't you doing anything about it? Do you have a better method
that works within the spirit of Mr. Crocker wishes, namely no change the
PROTOCOL!?
Or are you waiting for developers to solve it for you?
Well, I have done something and have provided AMPLE envidence that it helps
solve 80% of the spammer problem.
If you want to help solve the weaknesss, great. Yakov gave a few and so did
you. But that does NOT mean it will not work.
I'm not trying to show that it does not work.
Than what are saying?
I'm trying convince YOU to show two things, which you have not yet shown:
I sure have!
(1) WSCAP works _better_ than a system such as LMAP that uses something
lighter weight than SMTP for the callbacks.
I sure did! Check out the statistics I provided.
http://www.winserver.com/public/antispam/stats/stats-2003-nov.htm
LMAP is similar to a RBL lookup at the connection level. RBL provides an
average of 76% success rate and WCSAP provided a near 90% success rate.
Which is EXPECTED because you are goint a STEP further than just checking
the domain.
Now I can 100% verify this by analyzing the WCSAP.LOG to see how any of the
rejects were MX and CONNECT based. But this is obvious.
(2) WSCAP does not impose an undue burden by requiring third-party
SMTP servers to disavow every forged address that appears to be
in their domain.
I didn't disclaim it was not an expensive process. What I said it is a
different issue altogether. It is a scalaribility and redundancy issue. It
is a DESIGN IMPLEMENTATION issue. It does not negate that fact that you can
SPAM PROOF to a large degree your system by simply validating the return
path.
Your response to (1) seems always to be to change the subject,
oh hogwash.
by saying "but WSCAP works now, and needs no changes to SMTP!"
Baloney, I did not say such a thing. What needs to CHANGE is the RFC
SPECIFICATION so that we have the ammunition to put a MAIL FROM: validation
into action and be able to do so LEGALLY! Right now, MAIL FROM is only
required for BOUNCING. If its required for bouncing then it should be
required for possible dynamic and instant validating is SO desired by a
system.
The last thing I want is be sued by SPAMCO being paid millions by Microsoft
or whoever to spam servers and the transaction is blocked due to an MAIL
FROM: conformity check.
We need to make SPAMCO responsible at the TECHNICAL level. Once it is
compliant, it is allowed thru, at which case, I dont' give flying $%# what
the mail is. That is NOT my problem as a SMTP mail server vendor.
The thread on which this message is a reply is actually an argument about
just the "needs no
changes" clause, which has become a rathole.
You keep dimissing (2) as a scalability issue, but please note that it
is not a scalability issue for the servers that deploy WSCAP -- it is a
scalability issue for servers that _ARE PROBED BY_ WSCAP.
It still a SCALABILITY issue! The system that is PROBED can restrict
connection access, which is PAR for the course. In addition, those attacks
are trackable!
And it is a larger scalability issue even than bogus DSNs. You've waved
your hands
a lot, but you haven't convinced me that this isn't cost-shifting on a
much larger scale than you imagine.
Are you are paper hat or what? Didn't I say that this will be come a
redundancy problem if it was widely deployed?
For the umpteen time, WCSAP is a BLACK BOX VALIDATION into the SMTP
process.
The REAL goal here is making the MAIL FROM: mandatory IN WRITING.
Once done, OPTIMIZED SOLUTIONS will come.
I don't know much clear I can get.
---
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