走入死路？重新从协议细节入手
    
     问题似乎走入了死路。由于一时没有了头绪，于是决定从协议细节入手理解这个问题。
    
     从协议通讯角度而言，由于用户使用的是代理服务器，那么所有起始建立的通讯要么通过类似透明的方式被代理服务器进行中转，要么就要用一条显式的指令（应用代理）进行指向，或者用特别组合的协议包（Socks代理）进行指向。针对此用户使用的应用代理的特点，那么任何代理服务器起始建立的连接通讯都会有另外的连接去指定它发起这个连接。
    
     言下之意就是如果排除掉这条发送垃圾邮件的SMTP连接本身，一定应该有另外的连接中包含了对象连接的目标地址信息，以便指令代理服务器发起这条连接。那么究竟谁指令发起了那个SMTP连接呢？
    
     很简单，我们把捕获下来的内容中排除那条SMTP的所有数据，然后再进行查找，查找的目标内容就是那条SMTP连接的目标IP地址。
    
　　查找之前SMTP连接的目标IP 198.185.2.67（按照ASCII方式查找），获得以下结果：
　　图3：

让我们仔细看看这个包，这居然是个HTTP包，发送的HTTP内容为
“CONNECT 192.185.2.67:25 HTTP/1.0”

哦，事实恍然若现，CONNECT是HTTP Proxy协议中用来指令代理服务器发起向目标连接的命令，但是不一般的是，这个HTTP Proxy请求是发送到某台主机的25端口！

接下来进一步的情况是怎么样呢？
利用OmniPeek的Visual Expert中的应用负载分析功能，
图4：