Subj : RE: WCSAP-CBV False negative To : All From : HECTOR SANTOS Date : Thu Jan 31 2019 19:18:36 Date: Wed, 25 Jul 2007 11:47:32 -0400 From: HECTOR SANTOS To: DEAN BANKS Subject: RE: WCSAP-CBV False negative Newsgroups: win.server.smtp.&.avs Message-ID: <1185378452.46.1185376424@winserver.com> References: <1185376424.46.1185355977@winserver.com> X-WcMsg-Attr: Rcvd X-Mailer: Wildcat! Interactive Net Server v7.0.454.5 Lines: 223 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) .