A problem with some POP3 connections

[bspencer]

We recently stumbled upon an oddity with SmartDefense and wonder if anyone else has run into the issue. At this point, I am working with support on this, however, they do not seem to grasp the issue and I can't find any hint of others reporting such issues.

Configuration:
-) VPN-1 Power R62
-) an email server which is defined as a mail server and has POP3 protections enabled
-) Email Client: Specifically Outlook 2007 & (at least time) mobile devices which use Windows Mobile

Summary:
The clients connect (connection accepted by the gateway), issue authentication (accepted by SmartDefense) and are immediately disconnected with a TCP Reset (determined via network sniffing) which is sent to both the client and server by the firewall.

Observations:
-) I have SmartDefense logging the username. The log entry contains "mail security: Access attempt to mail server by " (note: the username is missing).
-) Other such POP3 connections are correctly accepted and logged (With the username) -- assuming they are using different email clients then the ones previously mentioned
-) This behavior can be simply reproduced when using telnet to simulate a POP3 client

Details:
Note: I am using telnet to test things mostly -- because it is very easy to control the commands sent and read the response. I am aware that telnet and the pop client may not be 100% the same.

Command: telnet <email server> 110
Tracker Entry: Connection accepted by the gateway
Response: <greeting from the POP server>
Command: AUTH
Response: <available authentications which the POP server allows>
Command: USER <username>
Tracker Entry: SmartDefense accepted the connection
Response: +OK username accepted
Command: PASS <password>
Network: Resets were sent

Notes:
-) if the AUTH command is removed from this process, normal POP3 processing works (resets are not sent)
-) undefining the mail server as a mail server allows the above process to work properly (resets are not sent)
-) the process isn't limited to these commands or this specific order. I believe it also fails with something like this: invalid_command -> USER -> invalid_command -> invalid command -> invalid_command -> PASS
-) The SmartDefense Tracker entry is always produces after the User command has been issued, without regard for any previous invalid/valid commands, but, before an authenticated connection is actually established
-) a username nor a password has to be provided -- just the commands. This includes providing an invalid username
-) sniff of the Outlook 2007 connection (someone else, not me): http://forums.microsoft.com/TechNet/...9227^SiteID=17

Questions:
1) Has anyone else experienced this? (i.e. is there something odd with our configuration)
2) Any thoughts on other tests I should run which would assist support? At this point, the tech doesn't totally seem to understand what I am saying given that tracker says it accepted the connection (Firewall & SmartDefense).

Thanks
Benji