[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Asrg] 0. General - Inquiry about CallerID Verification
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@solidmatrix.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.support@winserver.com>
To: "ASRG" <asrg@ietf.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@mx224.expts.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@mx224.expts.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@mx224.expts.biz>
> 20031128 03:44 00006104 S: 250 matthewwalker@mx224.expts.biz... Recipient
> OK.
> 20031128 03:44 00006104 C: RCPT TO: <123sxa23@alqwejad.com>
> 20031128 03:44 00006104 S: 250 123sxa23@alqwejad.com... 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@ietf.org
> https://www1.ietf.org/mailman/listinfo/asrg
>
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg