ietf-asrg
[Top] [All Lists]

Re: [Asrg] 0. General - Inquiry about CallerID Verification

2003-11-28 04:58:24
Incidentally,  WCSAP is written using our wcBASIC ;anguage CLR system.  Our
Wildcat! SMTP server calls the WCSAP p-code image which is also accessible
as a WEB service from our Wildcat! web server.

I made it available for demonstation:

http://www.winserver.com/public/code/html-wcsap?&xml=1&from=junkuser(_at_)solidmatrix(_dot_)com

Just make sure XML=1 is set to get XML/SOAP output.

Other options:

&debug=1     - text output (essentially the logger dupes the output to the
virtual console)

---
Hector Santos/CTO
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com


----- Original Message ----- 
From: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
To: "ASRG" <asrg(_at_)ietf(_dot_)org>
Sent: Friday, November 28, 2003 5:30 AM
Subject: [Asrg] 0. General - Inquiry about CallerID Verification


Yakov,

I am seeing things or what?

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%.

Am I seeing things?   Why isn't the group homing in on this method which
basically says that the return path must be valid?   I read the pros and
cons in the PDF you provided to me. It didn't make sense to me (the CONS).
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
    HELO/EHLO ---> helo/ehlo validate hook
    MAIL FROM:  ---> mail from validate hook
    RCPT TO: ---> recipient validation hook
    DATA: ---> mail filter validation hook  (3rd party software hooks)

We offer internal support for RBL at the connect level,  restrict
conformity
to HELO/ECHO,  local user validation at RCPT TO: and 3rd party hooks for
the
DATA level.   Now we added WCSAP (Wildcat! Sender Authentication Protocol)
to the MAIL FROM: state where the callerid verification takes place.

I added additional logic to make it even stronger.

If the CallerID verification process receives a 250 positive response in
the
RCPT TO: return path validation, the logic then goes a step further to
check
if the site is an open relay (see if will it accept any random address).

For example, here is a snippet of a WCSAP callerid verification session
for
an incoming return path.  This was spawned by our SMTP server once MAIL
FROM: <matthewwalker(_at_)mx224(_dot_)expts(_dot_)biz>  was issued by the 
remote MTA:

20031128 03:44 00006104 -------------------------------------
20031128 03:44 00006104 version: 1.34 / 1.3 (wcSAP)
20031128 03:44 00006104 uid    : 0
20031128 03:44 00006104 ip     : 64.200.120.224
20031128 03:44 00006104 cdn    : mx224.expts.biz
20031128 03:44 00006104 hdn    :
20031128 03:44 00006104 from   : 
<matthewwalker(_at_)mx224(_dot_)expts(_dot_)biz>
20031128 03:44 00006104 trying mx: mail.expts.biz ip: 64.119.222.7
20031128 03:44 00006104 # connecting to 64.119.222.7
20031128 03:44 00006104 S: 220 Simple Mail Transfer Service Ready
20031128 03:44 00006104 C: HELO localhost
20031128 03:44 00006104 S: 250 Hello, pleased to meet you.
20031128 03:44 00006104 C: MAIL FROM: <>
20031128 03:44 00006104 S: 250 Sender OK
20031128 03:44 00006104 C: RCPT TO: 
<matthewwalker(_at_)mx224(_dot_)expts(_dot_)biz>
20031128 03:44 00006104 S: 250 
matthewwalker(_at_)mx224(_dot_)expts(_dot_)biz(_dot_)(_dot_)(_dot_) Recipient
OK.
20031128 03:44 00006104 C: RCPT TO: <123sxa23(_at_)alqwejad(_dot_)com>
20031128 03:44 00006104 S: 250 
123sxa23(_at_)alqwejad(_dot_)com(_dot_)(_dot_)(_dot_) Recipient OK.
20031128 03:44 00006104 * Open Relay site: 64.119.222.7
20031128 03:44 00006104 C: QUIT
20031128 03:44 00006101 SMTP response code: 552
20031128 03:44 00006104 wcsap finish
20031128 03:44 00006105 -------------------------------------

Notice how we get a positive on the return path and a positive on a random
address.  This means this site is an open relay.  Without it,  the spammer
reaches the RCPT TO: state which in my opinion, is something you wish to
minimize allowing spammers to reach as it helps in thier learning logics.

Also,  I read little about JAMSPAM.

You probably discussed it already, but the technical standards should
indicate and emphasis 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."

Unlike others I read in the group, this is a TECHNICAL problem. Not a
social
issue.

The idea of "filtering the data" once the transport system has done its
job,
is purely a system level admistrative option and/or feature.  This is akin
to the FTP protocol.  In our system,  we offer a "Scan File" option once a
file is uploaded, but this is an admin/customer issue.  Has nothing to do
with the protocol itself.  The technical process must adhere to standards
otherwise it (the session) is rejected.

You want things to get moving,  get the proposals that concentrate on the
technical aspects of SMTP who do not have any association whatsoever with
mail content or links to "databases" that could make for questionable
non-technical restrictions.   That shouldn't be an SMTP issue.

The bottom line is that once a strict SMTP protocol is put in place, the
SPAMMERS will have no choice but to comply because those are the secured
technical rules.   In my view, this will clean up the spammer problem in
short order.  They must comply from a technical standpoint. Period.  It
has
nothing to with SPAM, really.

In any case, we are going to finally WCSAP CallerId Verification in our
Wildcat! mail system and go gamma with it next week to thousands of
customers.   Ironically,  I already even have received a concern from a
3rd
party Anti-Spam author saying "This is going to hurt our sales!"     My
response was simple: "non-conforming anonymous systems into the mail
transport is now going to be a thing of the past.  Mail from conforming
systems will be allowed to pass thru which is where your product comes
into
play with its mail filtering techniques optionally offer to the system
admin
and for users of the system."

The thing is, unless I am seeing things, with WCSAP, we are blocking
nearly
100% of the darn spam!  I have carefully looked at the looks for false
positives.  None!

I'm sure that spammers will eventually "conform" to technical standards.
In
my view, from a SMTP standpoint, that is all the IETF and this working
group
should care about.

As a mail processor/gateway developer for several networks over the last
25
years, I am firm believer in unaltered passthru of mail.  In my view, it
is
unethical to a) restrict mail reaching its destination and b) modify it in
any way.  However, that has nothing to do with technical conformity.  The
handshaking process should be an identified process on both ends.

On a similar note,  the RMX/DNS solutions, etc, are essentially the same
idea, but it requires DNS administration which in my view is going to be
problematic in all aspects, technically, politically, including
capitalistically (or communistically depending on your point of view).
Because of this, it will be slow to catch on.

However, one way to help the process is to include as part of the SMTP
specification, a DNS registration process.  This will force (encourage)
developers to include a "registration" process as part of their SMTP
software installation or setup process.  This registration process can
include other attributes, besides RMX related, such as "type of system."
Is
it open, closed (private) system?  Does the system offer open spam,
restricted spam, or no spam?  etc.

Of course, this extended attribute concept be implemented using EHLO,
however, if we are going to require a modified MX DNS system, then we
might
as well add other attributes to it as well.  A conforming client can use
this information and help save at least 1/2 of the bandwidth. A client can
also instantly inform a user or sender that the communication with a
target
system will be restricted in one form or another.

Nonetheless, compared to a CallerID Verification concept,  the extended
DNS
based solutions is going to be  a slow and costly endeavor. In my view,
Return Path callerid ID handshaking seems to be a very logical extension
to
the SMTP client/server handshaking process.  In the current form of SMTP,
it
works fantastic.   If we anticipate this is going to be a widely accepted
practice for all developers (big, including small, a major plus reason why
it will be accepted faster than a DNS based solution), then maybe we
should
look at reducing handshaking requirements to accomplish a callerid
verification SMTP logic.

Anyway, what at the flaws in a CallerId Verification that I am not seeing?

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




_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg