Subj : RE: WCSAP-CBV False negative To : All From : DEAN BANKS Date : Thu Jan 31 2019 19:18:36 Date: Wed, 25 Jul 2007 19:48:42 -0400 From: DEAN BANKS To: HECTOR SANTOS Subject: RE: WCSAP-CBV False negative Newsgroups: win.server.smtp.&.avs Message-ID: <1185407322.46.1185378452@winserver.com> References: <1185378452.46.1185376424@winserver.com> X-WcMsg-Attr: Rcvd X-Mailer: Wildcat! Interactive Net Server v7.0.454.5 Lines: 246 Hi Yes, I do believe this would work, great idea. I didn't, at the onset, tell you I very much like the overall operation of wcSAP,I wish I had started using it sooner, thanks for your hard work on it. On 2007-07-25 11:47 AM, HECTOR SANTOS wrote to DEAN BANKS: -> Thinking about this, I think I have a proposal, but I want to make sure you -> understand the key point: -> -> The key point here is that in the AVS world, our philosophy has been is -> that the best you can do today is look for the MOST OBVIOUS of all SMTP -> relaxation flaws - with WCSMTP/WCSAP we are address the obvious issues that -> are the heart of SPAM related issues. -> -> When using the RSET to test -> -> - NULL return path, 1 RCPT fake address -> -> transaction, you are within the whelm of a "operation valid" SMTP system. -> The results can not be used. -> -> But when doing a: -> -> - NULL return path, 2 RCPT, one direct, one fake address -> -> transaction, this is TYPICALLY not acceptable, it is not operationally -> valid, and it is exactly the 1 single idea of what we are testing for. -> -> If you go beyond this, then in my opinion, you are OUTSIDE the CBV test and -> you just doing a plain OPEN RELAY test. -> -> In WCSAP/CBV, we are not looking for that. I think an plain OPEN RELAY -> test is separate and different than a CBV. It can explain why a CBV target -> address is always accepted. But in this case, you would be rejecting -> because of an OPEN RELAY. -> -> In short, if we did this, then they would be no need to test the target -> address. Just do the fake address OPEN RELAY test. -> -> S: 220 Smtp service ready -> C: NOOP WCSAP v2.09 Wildcat! Sender Authentication Protocol -> http://www.santronics.com -> S: 250 OK -> C: HELO tka.com -> S: 250 mta169.mail.re2.yahoo.com -> C: MAIL FROM:<> -> S: 250 null sender <> ok -> C: RCPT TO: -false email- -> S: 250 recipient ok -> C: QUIT -> -> and if we did that, then we really don't know if the address is valid or -> not. We have no confidence whatsoever if the actual target address test -> was not done. All we know that the remote host will most likely accept it -> because it actually accepted a FAKE ADDRESS. -> -> Maybe what we can learn from this is that we can REVERSE the testing? -> -> Test #1 - Perform Open Relay Test -> -> If accepted, then they is no need to test for the target -> address. Just a return a WCSAP/CBV "pass" -> -> If the open relay is rejected, then test #2: -> -> Test #2 - Perform Target Address test -> -> Issue a RSET, test the target address. -> -> If accepted, return a WCSAP/CBV "pass" -> If reject, return a WCSAP/CBV "fail" -> -> Doing it this way has some merit and might "fit" a wider mix of operations -> better. -> -> What do you think? Essentially, reverse the TARGET/FAKE address test to -> FAKE/TARGET? -> -> -- -> HLS -> -> -> On 2007-07-25 11:13 AM, HECTOR SANTOS wrote to DEAN BANKS: -> -> > On 2007-07-25 5:19 AM, DEAN BANKS wrote to HECTOR SANTOS: -> > -> > > Hi -> > > -> > > Thanks for looking at this, I think you may have missed my point however. -> > > -> > > I'm talking about a false NEGATIVE, not positive, the goal of testing for -> > > an open relay is missed, in this instance, the rejection is for a different -> > > reason. -> > > -> > > The log file shows that the false email address is never being evaluated -> > > as local/relay, it's being rejected solely based on the server only -> > > accepting 1 RCPT TO: / connection (configuration of the mail server). -> > > -> > > Consider this SMTP dialog from an open relay that accepts 1 RCPT TO: / -> > > connection: -> > > -> > > S: 220 Smtp service ready -> > > C: NOOP WCSAP v2.09 Wildcat! Sender Authentication Protocol -> > > http://www.santronics.com -> > > S: 250 OK -> > > C: HELO tka.com -> > > S: 250 mta169.mail.re2.yahoo.com -> > > C: MAIL FROM:<> -> > > S: 250 null sender <> ok -> > > C: RCPT TO: -valid email- -> > > S: 250 recipient ok -> > > C: RSET -> > > S: 250 OK -> > > C: MAIL FROM:<> -> > > S: 250 null sender <> ok -> > > C: RCPT TO: -false email- -> > > S: 250 recipient ok -> > > C: QUIT -> > > -> > > Now we have uncovered an open relay that currently would be missed. -> > -> > I see your point, but no, not really. -> > -> > From an automated standpoint, the usage of RSET does not necessarily show -> > whether the rule is a 1 RCTP rule. -> > -> > To the SMTP protocol, what is really going on here? -> > -> > - 1 RCPT per connection? -> > - 1 RCPT per NULL return path? -> > - A "good guy" internal INBOUND "accept all" box? -> > -> > In other words, would it be any different if the MAIL FROM: return path was -> > not NULL? -> > -> > I would be uncomfortable REJECTING a target address solely based on RSET -> > open relay test. -> > -> > What we are looking for with WCSAP/CBV are essentially SMTP flaws or -> > violations in the transaction, not accuracy in the validity of an address - -> > that would be very hard to achieve. -> > -> > The WCSAP/CBV "Flaw" test is: -> > -> > a) the initial direct RETURN PATH address is not rejected, and -> > b) the "quick" false address was not accepted. -> > -> > You're saying the false address (b) test is not accurate because we might -> > need a RSET in there in order to be more accurate. -> > -> > What I am saying is that while it is possible for a RSET method may be -> > positive (false address is accepted), it would not ALWAYS be a valid test. -> > -> > In most servers, a NON-NULL return path and authentication is required -> > before a relay can be even considered. The point is that you just happen -> > to come across a particular type of SMTP server that has this 1 RCPT rule -> > configuration and possibly the 1 RCPT rule for the NULL return address. -> > -> > Could a RSET resolve that? -> > -> > Possibly. But I doubt that would apply to all servers and in fact, might -> > even increase the FALSE POSITIVES (overall resullt is a rejection) and the -> > emails are "falsely" not accepted. -> > -> > What I am saying is this: -> > -> > A CBV is not going to work across the board to order to get obtain the -> > VALIDITY of a return path. The best you can do is test for the most -> > obvious of zombie machines - those that accept all addresses regardless of -> > what you throw at it. -> > -> > When you attempt to get achieve "TRUE" accuracy by including a RSET, you -> > might find that the SMTP SERVER is one that accepts everything regardless -> > simply because it does not perform a dynamic SMTP recipient check - it does -> > mail delivery checks AFTER it accepts an email. -> > -> > You illustrated this point with the RSET example above. One might conclude -> > not a 1 RCPT rule, but a NON-NULL rule. WCSAP/CBV just don't know what is -> > actually going on here. -> > -> > In this case, the overall WCSAP/CBV result would be a REJECT and in my -> > opinion, this would have a higher probability for a false positive. -> > -> > Only a human can tell you. But what I say is that the attempt to be -> > 'accurate' can actually increase the false positive possibility. -> > -> > When you consider all the possible issues, scenarios, there is really one -> > test you can do - check for a clear ZOMBIE or OPEN RELAY machine that -> > accepts everything regardless of what you do. That is the BEST you can do -> > with a CBV. I don't think using a RSET is going to help it and might even -> > lower its effectiveness. -> > -> > That said, I am going to add a RSET option to WCSAP/CBV to allow people to -> > explore it. -> > -> > Do you understsand the point here? -> > -> > It comes down to this: -> > -> > - ACCURACY OF "BAD GUY" OPEN RELAY TEST: -> > -> > USING RSET is lower than NOT USING RSET -> > -> > - ACCURACY OF "GOOD GUY" OPEN RELAY TEST: -> > -> > NOT USING RSET is lower than USING RSET -> > -> > I guess it all comes down to what is a "Bad or Good" guy/system. -> > -> > If the system is truly BAD, then its will ACCEPT the fake address -> > regardless. We are concluding that accepting a fake address regardless of -> > using rset or not, is a BAD CONDITION we are looking for. We reject the -> > overall transaction. -> > -> > If the system is truly GOOD, then it comes down to what is more "accurate" -> > -> > - rejecting based on not using RSET -> > - rejecting based on using RSET -> > -> > I say we have NO MEASURE of accuracy for the GOOD GUY - so in the -> > philosophy of WCSAP/CBV - you punt - you accept the target address because -> > you can not really tell for sure what is going on. -> > -> > If we use the RSET, then as you showed, it could be an open relay - but may -> > not be because delivery can be tested AFTER the data is accepted. -> > -> > -- -> > HLS -> --- Platinum Xpress/Win/WINServer v3.1 * Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013) .