Endpoint Protection

Hi,

  I originally posted this question here: http://community.norton.com/t5/Norton-Internet-Security-Norton/Endpoint-Protection-causing-SMTP-connections-to-Azure-to-go-idle/td-p/657865.

  We have developed an SMTP-client/-server application and are running the server on the Microsoft Azure Cloud. Doing this, we found that emails were taking a long time to send--50+ seconds--often timing out and failing. After opening a support call with Microsoft, we found the causing factor is an application called "ccApp.exe" (which I believe is part of Symantec Endpoint Protection, and monitors email traffic for viruses[?]). Killing the ccApp process resulted in emails being sent quickly and successfully.

  Getting a bit technical now: Doing a network trace, we can see that when ccApp is not running, our SMTP traffic sends the following commands:

    HELO, MAIL, RCPT, MIME, DATA..., QUIT

  ..however, when ccApp is running, the SMTP traffic looks like this:

    HELO, MAIL, RCPT, RSET, <delay 50+ seconds>, RSET, MAIL, RCPT, MIME, DATA..., QUIT

  ..so I am guessing that ccApp is hooking winsock and injecting SMTP commands into our emails. The problem is that after ccApp sends the first RSET and the server responds OK, nothing happens for 50+ seconds. Azure will kill a connection if it's idle for more than 60 seconds, so this can cause our emails to fail. If ccApp does respond before this 60 second time-out, the second RSET is sent, and with no delay, so too is the rest of the message.

  Another thing to note is that if we run our SMTP-server on a machine on our local network, there is *no* delay between the RSETs, and if we run our server on an Azure emulator (running locally), there *is* a 50+ second delay, so it makes it look like the problem is specifically between ccApp and Azure (live or emulated). It should also be noted that when running on Azure, our SMTP-server sits behind a load-balancer.

  So, I'm wondering: what is ccApp doing during all these 50+ seconds? And is it something a load-balancer could be affecting (for example, every time an email is sent to the IP address of our server, the load-balancer will push the request off to one of a number of machines (through a unique private port). Is it possible that ccApp could notice something like this and heuristically freak-out)?

Thank you,
Kind regards,
Eliott

ccApp.exe is the mail scanning component of SEP.

Why it's taking so long to send off the second reset to the server is baffling.

As you indicated, removing the component allows the message to be sent quickly. 

But not always.

In your test environment, can you verify the %temp%\scclog.txt   is it large?  Is the system having trouble writing to this file.

Try removing the file and than firing off an e.mail, does that help?

Thank you for the reply Jason,

  I took a look for this scclog.txt file, but cannot find it (done a full search of my hard-drive too). Is it possible for this file to exist remotely (I don't know how our network administrator configured this)?

  I also tried using the Sysinternals' tool, Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645) to watch what ccApp.exe was doing during the email send, and the only file I could see it touch was a temp file, CC18E4.tmp, which it deleted immediately after processing.

  During the +50 second idle time, the only thing Process Monitor shows it doing is a "Process Profiling" action once every second (which it appears to be doing constantly, regardless of whether it's processing an email). Otherwise, up until this delay and after it, everything it does happens very quickly.

Thanks again,
Kind regards,
Eliott

[Edit] Just noticed one other thing it does during its idle time. Right in the middle of the delay, it opens a registry key "HKLM\Software\Symantec\Common Client\WorkingSetGarbageCollector". Don't know if that's useful.