[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Asrg] 0. General - Inquiry about CallerID Verification
Yakov,
Here is an interesting WCSAP session:
20031128 06:25 0000631e -------------------------------------
20031128 06:25 0000631e version: 1.36 / 1.35
20031128 06:25 0000631e uid : 0
20031128 06:25 0000631e ip : 62.73.34.162
20031128 06:25 0000631e cdn : palvelin.tomi-steel.fi
20031128 06:25 0000631e from : <hitmang@theglobe.com>
20031128 06:25 0000631e rbl : 0
20031128 06:25 0000631e relay : 0
20031128 06:25 0000631e hdn :
20031128 06:25 0000631e trying mx: blackhole.theglobe.com ip: 127.0.0.2
20031128 06:25 0000631e # connecting to 127.0.0.2
20031128 06:25 0000631e S: 220 winserver.com Wildcat! ESMTP Server
v5.7.450.9b10 ready
20031128 06:25 0000631e C: HELO localhost
20031128 06:25 0000631e S: 250 winserver.com, Pleased to meet you.
20031128 06:25 0000631e C: MAIL FROM: <>
20031128 06:25 0000631e S: 250 <>... Sender ok.
20031128 06:25 0000631e C: RCPT TO: <hitmang@theglobe.com>
20031128 06:25 0000631e S: 250 <hitmang@theglobe.com>... Recipient ok
20031128 06:25 0000631e C: RCPT TO: <123sxa23@alqwejad.com>
20031128 06:25 0000631e S: 250 <123sxa23@alqwejad.com>... Recipient ok
20031128 06:25 0000631e * Open Relay site: 127.0.0.2
20031128 06:25 0000631e C: QUIT
20031128 06:25 0000631e result : -7
20031128 06:25 0000631e SMTP response code: 552
20031128 06:25 0000631e wcsap finish
20031128 06:25 00006323 -------------------------------------
I updated the code to pass "Relay Allow" information to the WCSAP session.
This is passed on the remote MTA being allowed to route mail or not. In
this, he is not allowed (Relay: 0). But he has a MX record that points
to 127.0.0.2, which points back to my server. I already added logic to
check for MX=127.0.0.1. But missed this one. I'm going to change it to do
a 127.0.0.* mask check.
But since it was a local connection, it came back into my server and the
fake open relay address check returned a positive result. However, since he
was not allowed to do relaying, a 552 response was sent back!
So checking for open relay on a callerid verification pass, coupled with a
"Allow Relay" flag is enough to handle this situation. If Allow Relay is
true for the remote MTA, the second check is skipped.
Please note the entire session takes less a minute (I should print the
seconds to get actual rates).
I don't see any flaw in this logic. Anyone care to comment?
---
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