Hirelay.
I recently started using wcSAP, and have noticed what I'd consider a
false negative (allowing potential spam). In the log file clip below, the "wcsap-openrelay-test-123sxa23@alqwejad.com" address is rejected because
the server only allows 1 RCPT per connection, not because it's trying to
Perhaps after the 1st RCPT is sent and accepted a RSET command could be issued before the 2nd one is tested.
On 2007-07-22 11:01 AM, DEAN BANKS wrote to ALL:about it:
Hi
I recently started using wcSAP, and have noticed what I'd consider arelay.
false negative (allowing potential spam). In the log file clip below, the "wcsap-openrelay-test-123sxa23@alqwejad.com" address is rejected because the server only allows 1 RCPT per connection, not because it's trying to
Hi Dean,
Its not a false positive because it isn't a reason for rejection. The goal was to check for an open relay, nothing more. If it rejected it, then the expected discovery was complete.
Now, if it did accept the FAKE ADDRESS, then it would be viewed as an open relay. But it didn't accept it which for any reason it may have, it is the main end goal to be ascertain.
Remember, the CBV returns a "postive test" - the target address did not fail. So its not a false positive.
If you are saying the ADDRESS was "really bad", CBV still did its job because there is NO WAY to determine this. The GOAL was to see if the SMTP server A) directly rejected the address or B) it is an open relay as one reason for accepting it.
Perhaps after the 1st RCPT is sent and accepted a RSET command could be issued before the 2nd one is tested.
That means you are literally trying to start a NEW transaction which is not want we want here and it won't give you any different result - think
- WCSAP CBV WAY:
TEST REAL ADDRESS:
MAIL FROM: <real address>
250 OK
TEST FOR OPEN REPLY
MAIL FROM: <fake address>
550 SORRY BAD ADDRESS OR EXTERNAL DOMAIN
THIS IS A GOOD SMTP SYSTEM (behaving right).
- Lets try it your way:
TEST REAL ADDRESS:
MAIL FROM: <real address>
250 OK
TEST FOR OPEN REPLY USING A RESET
RESET
250 OK
MAIL FROM: <fake address>
550 SORRY BAD ADDRESS OR EXTERNAL DOMAIN
If you are saying it should accept this because it is now a 1 RCPT new transaction, then it still would be an OPEN RELAY because it should not be accepting this fake address.
This WCSAP CBV logic is very good logic based on the best current practice (BCP) and expectations of systems. Whether or not it only accepts 1 RCPT which would be not the BCP, the goal was to see if it accepts JUNK as it could be the reason it also accepted the target address.
Think about it more. WCSAP is now 4 years old of solid, time tested engineeirng SMTP CBV logic. It is designed to eliminate the obvious by analyzing expected "failure or bad" conditions - the open relay is considered a bad condition in today's environment. It doesn't say the return address is GOOD, it just says that it pass the failure test.
Hope this helps
--
HLS
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.
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
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:however.
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
testing forI'm talking about a false NEGATIVE, not positive, the goal of
differentan open relay is missed, in this instance, the rejection is for a
path wasreason.
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
address -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
doesthat 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
concludemail delivery checks AFTER it accepts an email.
You illustrated this point with the RSET example above. One might
what isnot a 1 RCPT rule, but a NON-NULL rule. WCSAP/CBV just don't know
can doactually 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
people towith 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
but mayexplore 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 -
not be because delivery can be tested AFTER the data is accepted.
--
HLS
| Sysop: | Nelgin |
|---|---|
| Location: | Plano, TX |
| Users: | 577 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 57:14:13 |
| Calls: | 9,294 |
| Calls today: | 2 |
| Files: | 16,016 |
| Messages: | 1,046,602 |