+1 to all of Murray's points here, including the final one about the ASRG ;-)
Ned
I don't think one can tell whether a particular client is connection caching
by observing protocol activity in terms of time between commands/disconnect.
I
also don't think one can tell based on those same data whether any delays are
caused by deliberate software action, CPU scheduling, network latency, or
anything else. I might make that conclusion if I saw a client sending
periodic
RSET or NOOP commands, but I haven't seen any evidence of such.
If someone thinks (for example) that Facebook might be connection caching and
wants to find out for sure, one could always go and ask them.
I also have my doubts that the bad guys are implementing connection caching.
Spammers have such enormous compute and network power at their disposal (when
using botnets, at least) that they are probably not thinking too much about
efficiency in terms of establishing new connections, which only adds
complexity
and makes their code bigger. And, as far as I'm aware, bots typically try
to
do direct connections rather than relaying, and they tend to carry their own
MTAs and even TCP stacks with them to avoid detection. That means they're not
using the open source MTAs that tend to implement connection caching, so those
connections that do show some idle time are probably not the bad guys.
So, so far, I haven't seen anything that warrants consideration in terms of
updating a standard. I suggest that there are way too many assumptions being
made about the data to warrant much action from the IETF, even something
informational.
This is starting to sound like a conversation the ASRG might enjoy rather
than this forum.