There are several things to keep in mind here:
1) Did the alarm fire?
According to your email, the alarm did fire.
2) Did the IPLOG get generated?
You can look in the /usr/nr/var/iplog directory or the /usr/nr/var/iplog/new directory for hte IPLOG file that would have been generated. The IPLOG should be named with the ipaddress of the source of the alarm.
I recommend using the tool etheal to view the contents of the IPLOG to see what happened to the connection after the alarm fired. Ethereal can be downloaded from www.ethereal.com.
3) Did the TCP Reset get executed?
The only way to verify if the TCP Reset was actually executed is to sniff the network as the attack takes place. Since you are creating the attack yourself you can run the following command on the sensor as user root: "snoop -d spwr0 " to sniff the traffic between your machine and the email server. If you are using the IDS-4210 then change spwr0 to iprb0.
You chould see the connection and see Reset packets after the alarm fires.
Things to keep in mind:
a) If spanning off of a switch port then the switch may block these Reset packets from the sensor.
b) The Resets do not always work. They are the sensor's best guess at the connection sequence. Version 3.0 does a little better job, but it is still not guaranteed to work.
c) Some email clients will re-establish and complete the email even after having been Reset.
You can also look at the IPLOG to see what happened after the alarm fired to see if the connection was reset and restarted.
4) Was the connection Blocked?
To block the connection you would have had to setup the sensor to control the acls on a router between your machine and the email server. Check to see if the acls were created, and check to see if they actually do block the packets. The acls may be applied to interfaces which do not affect your traffic. Also there is a small time delay from when the alarm fires and the acls are updated. During this time delay the email could have been completed and sent. So only traffic after that may have been blocked.
Once again check to see if the connection continued after the alarm fired by checking the IPLOG file. If the connection continued then the router acl changes did not block the connection.
