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:13:44 -0400 From: HECTOR SANTOS To: DEAN BANKS Subject: RE: WCSAP-CBV False negative Newsgroups: win.server.smtp.&.avs Message-ID: <1185376424.46.1185355977@winserver.com> References: <1185355977.46.1185322583@winserver.com> X-WcMsg-Attr: Rcvd X-Mailer: Wildcat! Interactive Net Server v7.0.454.5 Lines: 144 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) .