Keith Moore wrote:
On Aug 26, 2011, at 8:18 PM, Hector Santos wrote:
Among the spammers rejected with delays, many do try a new transaction
with the same failed result. Is this CS client behavior? It seems to
appear that way.
Maybe the spammers are trying to deal with greylisting?
Yes and some are Keith. This was discovered as a greylist loop hole
as you may recall with the thread back in May - "RSET - possible
security loophole." It raised the discussion level regarding the
recording/tracking/clearing differences of Session Level vs
Transaction Level status info.
I added logic to my greylister filter to pass back this rejection
status to SMTP to disable all any more transactions at the section
level. I didn't have it just drop per SMTP. I have logs to show it
works to prevent these greylisted client attempting to hold and to try
again. It also was great to see how it stop qreylist rejected clients
not delaying but trying other different MAIL/RCPT transactions. I
have one of these yesterday that no delays
09:19:00.654 C: MAIL FROM:<Phonesforbusiness(_at_)magicshackers(_dot_)com>
09:19:00.655 S: 250 <Phonesforbusiness(_at_)magicshackers(_dot_)com> ok
09:19:00.720 C: RCPT TO:<sysop(_at_)santronics(_dot_)com>
09:19:00.894 S: 250 <sysop(_at_)santronics(_dot_)com>... Recipient ok
09:19:00.940 C: DATA
09:19:00.941 S: 354 Start mail input; end with <CRLF>.<CRLF>
09:19:01.055 ** end of data received. (bytes: 4166) (31.9 K/s)
09:19:01.409 ** WCX Process: SmtpFilterHookLoader ret: 0 (354 msecs)
09:19:01.409 S: 451 Please try again later (TempFail)
09:19:01.455 C: RSET
09:19:01.455 S: 250 Reset State #1
09:19:01.502 C: MAIL FROM:<TermLifeInsurance(_at_)magicshackers(_dot_)com>
09:19:01.502 S: 451 Transactions disabled due to policy.
09:19:01.548 C: QUIT
09:19:01.548 S: 221 closing connection
09:19:01.563 ** Completed
But now I am wondering if we gave them the ones that did delay too
much credit and it was just client software behavior. I see the
following types with 2nd transactions:
1) same MAIL and RCPT
2) same MAIL and different RCPT
3) different MAIL and/or RCPT
By far, I see #2 and #3, but with no CS mentality, you would think the
first one was the greylist loophole I observed. With a CS mentality,
it may not be a loop hole per see, instead a result of client software
behavior possibly seeing the same queued file remaining X secs later.
A honest explanation or indeed they were clever to see use CS to
help get around greylisting without scheduling a new connection.
--
Sincerely
Hector Santos
http://www.santronics.com