ietf-smtp
[Top] [All Lists]

Re: FWIW Connection Sharing Stats

2011-08-27 09:57:50

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


<Prev in Thread] Current Thread [Next in Thread>