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 gmail.com 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.
--
Sincerely
Hector Santos
http://www.santronics.com