[Top] [All Lists]

Re: FWIW Connection Sharing Stats

2011-08-26 19:32:22

Murray S. Kucherawy wrote:

How are you able to distinguish between an SMTP client that's implementing connection sharing and one that is not?

Good and fair question which highlights part of the dilemma.

Sure, we don't know for sure what the clients are actually doing. All I have is the data in front of me, a history of unexplained patterns attributed only to "bad guys" behavior and now a new recognition that helps explains it all.

If Connection Sharing means that client connects, sends a transaction or get rejected at EOD, holds for X time and tries again or issues QUIT, then:

   I have very few of multi-transactions that have QUIT delays, and
   a good significant amount with QUIT delays between 5 and 260 secs
   with 1 transaction or rejected transaction.

Among the spammers rejected with delays, many do try a new transaction with the same failed result. Is this CS client behavior? I seems to appear that way.

So the lack of multi-transaction among the domains with delays, lowers slightly but not taken the idea they are probably software with an online hold for mail concept.

The other clue is the persistent nature of the delay values among the sessions from the same domains, like Facebook with 5 seconds, google with 30, hoffman with 6, even with spammer domains, etc.

I saw only hoffman send multi-transaction sessions and google with 30, I did a manual test by logging on o to send two messages ~10 seconds apart. On the server side, a single session logs showed the 1st transaction, then 10 secs later the 2nd transaction was sent. So I will google is using the "Connection Sharing" or like idea.

On the other hand, how do you explain Facebook when two clients arriving at the same precise microsecond and each sent 1 message and each waited 5 secs to QUIT. Why didn't it use one session for these two messages? I can only presume it could be a configuration issue or two different clients looked at two different queues in their outbound farm. Who knows?

But because of Facebook's persistent nature of 5 secs delay, I will tend to think it is using this for CS but for some reason its not working for them. Otherwise what is their purpose of waiting 5 secs?

All I can conclude is:

  - The bad guys are also using the same good guys software
    with this "Connection Sharing" idea because it explains the
    common behavior among all with these delays,

  - The higher delay is needed to better pick up 2 messages
    making it worth while for the client, but

  - They are not tuned to associate rates vs the hold time
    which is probably very much dependent on the frequency
    of mail going to a host receiver.


Hector Santos