----- Original Message -----
From: "Yakov Shafranovich" <research(_at_)solidmatrix(_dot_)com>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: "ASRG" <asrg(_at_)ietf(_dot_)org>
We have the CallerID Verification system now in place for at least 4-5
days.
This method has drastically reduced the spam via unverified return
paths,
but practically 100%.
The method you are refering is similar to what is more commonly known as
"Challenge/Response" (C/R). Majority of C/R implementation actually send
a message back to the sender asking him/her to click on a link to reply
to the message in order to verify that the sender exists.
Not the same thing. WCSAP checks the MAIL FROM: state point. C/R
systems go to the RCPT TO: statement, and in some cases complete the
session. In our early exploration of this almost two years
ago, it immediate apparent that it doesn't belong in the SMTP protocol, it
is intrusion for our business customers and it doesn't quite work to solve
the spammer problem. It is easily broken with a little bit of automation.
There are problems with the the regular C/R approaches that apply here
as well:
1. Nothing stops a spammer from using someone else's email address with
that domain answering yes (unless you start matching the his email
address with his IP which is what the LMAP proposals do). Especially
this would be true if he uses YOUR domain.
Our mail system does (optionally) check the return path domain against the
connection IP. But more importantly, this puts the spammer into another
category, namely, outright fraud.
Also, as per RFC 2822 you
must support MAIL FROM: <> which basically allows spammers to bypass
everything at this step.
True, but that puts it into another category handle by other technical SMTP
server designs.
2. Even checking MAIL FROM does not prevent spammers from forging the
"From" header inside the actual email message.
Doesn't apply. Again, the goal is no minimize reaching the RCPT TO: /DATA
state in the SMTP state machine.
While there are numerous problems with regular C/R, your particular
approach has some issues as well:
1. Nothing stops a spammer from using his own domain which answers "yes"
to all RCPT TOs to that domain (BUT not an open relay).
2. ISPs tend to play around with RCPT TO: handling such as answering
"yes" to all requests, or delaying responses in order to make sure
spammers do not use RCPT TO: for harvesting email addresses.
Again, this is to verify the existence of the domain which is a good bit of
the problem, and in addition, helps address the fraud.
3. Since your proposal operates at the MAIL FROM step, if the sender's
receiving MTA is off-line this process will fail. This will also be a
problem if the sender is using GreyListing
(http://projects.puremagic.com/greylisting/). According to RFC 2821,
section 4.5.4.1., the originator must be able to resend email several
times when temporary failure occurs, which in practice happens sometimes.
Handled with a 4xx response when the connect and/or welcome response
indicates so.
As I noted to you via EMAIL, our system allows for programmable hooks
at
each step of the protocol state machine:
connect --> connect IP validate hook
Would this be an rDNS / RBL hook?
Yes. As it is currently implemented, plus admins White/Black IP lists.
HELO/EHLO ---> helo/ehlo validate hook
What kind of hook are you using here? If a spammer uses a valid domain
here, nothing stops him. Only something like LMAP/DRIP that ties IP
addresses with domain names for SMTP can help against that.
As currently implemented, our server offers strict HELO requirements (for
intranets), but internally the server watches for fake domains, badly
formatted dot IP addresses, etc. This has help eliminate a large
percentage of the illegal entry attempts. Here is a log snippet:
**************************************************************************
Wildcat! SMTP Server v5.7.450.9b10
SMTP log started at Fri, 28 Nov 2003 01:21:31
Connection Time : 20031128 01:21:30
Client IP Address: 24.92.200.21 (unknown)
SSL Enabled: NO
01:21:31 S: 220 winserver.com Wildcat! ESMTP Server v5.7.450.9b10 ready
01:21:31 C: HELO 208.247.131.9
01:21:31 S: 501 Invalid HELO client address.
Since implementing a HELO/EHLO check, we have noticed a drastic redundant of
certain type of spammers stop connecting to our system. Their "software"
does not work here.
MAIL FROM: ---> mail from validate hook
What kind of hook aside from this proposal are you using here?
In our SMTP server design, just wants a response from an external source.
Currentlty, we have optional strong MAIL FROM: requirements (for intranets).
We implemented the WCSAP hook. And I recently contacted you to see if how
fast I can test our a "wcRMX" hook. But that C code was not "API" or coder
ready. I started a small effort to make it useable as a API but then said,
"What about the DNS database?" It am sure it will work, but this presents
an entirely different non-dynamic "administrative" non-technical issue.
What happens with 4xx codes? or if the MTA is off-line?
Supported. 4xx is used for MX and/or MTA connection failures. WCSAP also
includes a "TryMXOnce" where per the RFC if there is no MX, it tries the
DOMAIN IP. Just a standard mail sender.
JamSpam seems to be currently dead. The folks involved could not agree
on anything so it fell apart.
Maybe so, but I am not too sure if they did not accomplish the goal of
allowing a legitimizing a classification of spam to be unrestricted at the
system level. This "David" guy did attend the congressional hearings. Was
IETG represented?
I have not read the ANTI-SPAM congress bills yet, but from what I
understand so far, it sounds like it may have opened up the opportunity for
spammers to claim tortious interference against an ISP or for that matter,
mail software vendor. This is why I believe we need to make sure the SMTP
PROTOCOL and its "access" methodologies are purely technical in mind based
on security aspects of the system. The SMTP protocol should have NO
business in the analysis of mail content, with the exception of possibility
checking headers for technical conformity.
You probably discussed it already, but the technical standards should
indicate and emphasize restrictions to the transports protocol is purely
technical. EMAIL SYSTEMS invalid handshaking is all the IETF should be
looking at to simplified this process. To go any further, simply will
complicate things and give JAMSPAM proponents a reason to exist. Their
layman argument is purely based on the legacy operations of the SMTP
system.
Imposed stronger state point handshaking and these people have no basis
for
argument other than "social."
What kind of controls are we talking about? Something like LMAP?
Any proposal that is based on authorizing the secured handshaking between
the client and server BEFORE the RCPT TO: is reached.
RFC 2821 states (sections 3.3, 4.1.1.4 and 6.1) that the SMTP server ....
I clearly understand this.
It doesn't apply. This is after the client/server handshaking has been
negotiated.
It will only work if most of the mail systems on the Internet comply
with it. The IETF cannot force compliance with its standards.
Right, but the market will. Any current vendor (big and small) who is
serious about their mail server functionality in address the "spam problem"
will do something about it, especially the smaller vendors as it see it as a
market opportunity agains the bigger legacy systems. Its a common trait in
many industries where change is first followed by newer or smaller vendors.
Therefore, partly what we are seeking is an incremental solution as stated
in the
technical considerations document
In understand and I agree. This is why I like the RFC changes be made to
address stronger client/server negotiations at the TECHICAL level
elimination any notion that the protocol is in the business of many
"questionable" and "debateble" logic towards the mail content.
In my view, if IETG does not do this, you will force the "vendors" to move
towards a central authority entity concept, aka what the Verisign people are
proposing.
We are open to hearing how the existing SMTP protocol may be tightened
but its must be proven that this will solve the problem.
I think you got all the technical proposals already. Again, this is a
technical issue of resolving how a CLIENT and SERVER talk to each other.
You need to borrow technology has been in existence and worked in the past.
Such as Fidonet. Randy Bush (if this is the same person that was involved
with Fidonet) clearly knows how this system does work, yet, at the same
time, understands there are administrative nightmares when trying to
maintain a "membership database." This is probably why he is resistance to
DNSSEC and to a large degree why I don't particularity like the
ramifications of having a DNS membership database controlling access.
However, it can help the process to if this DNS database includes attributes
that augment the client/server negotiation process. For example:
Type of system: OPEN, CLOSE, SEMI-CLODE
Type of mail: SpamAllowed, Commerical Spam, No Spam
Hours: 0-24 SPAM: 1-3
etc, etc. Use the opportunity to not just address SPAM but other technical
issues the current mail transport specs do not address. Hours of operation
will HELP a growiing amount of the "small or home busines" operations with
limited bandwidth or non-full time mail operations. In Fidonet, there
was a few requirements. One was a ZONE HOUR where all operations must be
open for mail. We can extend this logic to include a "BOUNCE HOUR" or
"SPAM HOURS", etc.
In my view, a proposal that is based on a DNS modification will benefit
(more plausible) from extending the functionality of the system, not just ad
dresing spam.
I am sure that you will allow for more than "4-5 days of testing" before
deploying this.
We are going gamma sometime next week. Nothing better than getting excited
people to test it in real operations. Obviously, between you, I and the
fencepost, the first wave will be "more beta." <g>
IF you are rejecting email at the MAIL FROM stage, there is now way to
check for false positives since you do not have the actual email
message.
Doesn't apply. Again, I am from the SCHOOL that SMTP has no business in
analyzing mail content. That is what is going to get you in trouble and
FEED the legal eagles.
The goal is CONFORMITY of the client/server session. If a MAIL FROM:
FAILS, the client has no business going any futher. If the MAIL FROM:
succeeds, then WCSAP has done its part and it up to the next stages, if any,
to do checking.
This is why the RFC needs to concentrate their efforts in the first 3
states:
connect
HELO/EHLO
MAIL FROM:
The problems with AOL, YAHOO, etc with allowing all RCPT TO: is because of
the dearth of control at the above states. Solve this and the major issues
will be addressed. Then we might see the YAHOO, AOL, etc comply.
Additionally, your specific test installation might not be
large enough to extrapolate to the entire Internet. If you can provide
additional statistical information, that would be useful.
I got over 6 months of logs and collected mail that was accepted or filtered
at the DATA stage. Most of the false positives exist at the DATA stage
because of the external mail filtering rules in use. 3rd party software
such as wcSpamGuard for the WIldcat System (http://www.wssoft.net) hook
into the DATA stage and provide a suite of mail filtering methods for the
system and for users.
The following sections from the technical considerations document are
relevant:
" The idea of replacing SMTP is appealing because it
permits thinking in terms of creating an infrastructure
that has accountability and restrictions built in.
Unfortunately an installed base the size of the
Internet is not likely to make such a change anytime
soon. It seems far more likely that successful spam
control mechanisms will be introduced as increments to
the existing Internet mail service.
"
Yet to borrow a quote:
"The Internet was: small, friendly, open, casual.
The internet has become: Huge, Competitive, Closed/Open,
Casual/Formal."
An unaffiliated view of Electronic Commerce,
Dave
Crocker, 1995
So you see from this that Mr. Crocker fully understood back in 1995 where we
were heading. Corporations have ditched their NOVEL or X.400 system, or
Lotus Notes system, etc. The same vendors, including ourselves have
integrated internet technology into their software.
There is no REASON to believe it can't happen again.
Look, I have only one reason why we began efforts to add anti-spam solutions
into our system, my customers! They are the ones who want a solution or one
that makes it less of a problem. If I don't provide them, they LOOK else
where. Its that simple. I am not going to wait.
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