We monitor all high order ports, using a port based monitoring. We do not do any protocol signatures for high order ports.For ports 0 - 1024, we used a signature based monitoring. This means we are looking for a specific protocol on the low order ports. We do not listen on all ports, only those defined on the protocol page.
If we are monitoring HTTP on port 80, and traffic comes from port 81, we will not be monitoring that traffic. This can be modified on the protocols page.
Assuming that some protocol claims the port, or it's above 1024, signature identification kicks in. No matter what port it's on, if it looks like SMTP we will process it as SMTP.
The same applies to FTP traffic. While traffic may be initiated on port 20 or 21, during the transaction typically the port will be changed to some ephemeral port. In this case signature identification should allow us to continue to monitor that traffic.If no protocol claims by signature then we try to match by port. If there's a port match, we try to interpret the stream as the matched protocol. This would be if a TCP protocol defines the port.
What is the impact if you tie 0-1024 to SMTP? Monitor will scan all sub-1024 traffic and try to signature match it. If it matches a non-SMTP signature for an enabled protocol, that protocol will take precedence. If it matches SMTP, then we interpret the message as SMTP. However, if it looks nothing like SMTP, we will still try to interpret it as SMTP and results are undefined. This will probably chew a lot of reassembly buffer space up and will not be successful.