Passive ftp works fine with 3.0.16. The new predefined policy support passive ftp and no additional Global rule is needed.
As now there is no need to rely on Outgoing only profile. Using web profile http connections are restricted to the http port set defined in firewall common tasks.
I tested this on 3.0.16. It seems so :o
The rule description don’t mention NOT too :-
Please open a new topic to describe this bug.
The passive ftp rule actually excludes only the privileged ports, those below 1024. Any http (tcp out) to the 8000 series, for example, passes the passive ftp rule even if it is not in the http ports. See the attached 3.0.16.295 web browser default ruleset. The tcp request should just continue down the list if it is not in the http ports and be allowed if the port number is above 1024. And oddball http requests do not normally used the privileged ports.
[attachment deleted by admin]
You will get what you want if you delete the Passive FTP rule and the final block rule (or edit it so only blocks privileged ports)
EDIT: You may need a final ASK rule if you are not using Custom Mode.
That rule comply with passive ftp transfers requisites.
[b]Passive FTP[/b]In order to resolve the issue of the server initiating the connection to the client a different method for FTP connections was developed. This was known as passive mode, or PASV, after the command used by the client to tell the server it is in passive mode.
In passive mode FTP the client initiates both connections to the server, solving the problem of firewalls filtering the incoming data port connection to the client from the server. When opening an FTP connection, the client opens two random unprivileged ports locally (N > 1023 and N+1). The first port contacts the server on port 21, but instead of then issuing a PORT command and allowing the server to connect back to its data port, the client will issue the PASV command. The result of this is that the server then opens a random unprivileged port (P > 1023) and sends the PORT P command back to the client. The client then initiates the connection from port N+1 to port P on the server to transfer data.
From the server-side firewall’s standpoint, to support passive mode FTP the following communication channels need to be opened:
FTP server’s port 21 from anywhere (Client initiates connection)
FTP server’s port 21 to ports > 1023 (Server responds to client’s control port)
FTP server’s ports > 1023 from anywhere (Client initiates data connection to random port specified by server)
FTP server’s ports > 1023 to remote ports > 1023 (Server sends ACKs (and data) to client’s data port)
Anyway if you need an alert when passive ftp connection occurs I guess the current implementation of ask could handle this scenario as well (using train with safe ask is needed to prevent learning).
The rule works fine for passive ftp. But with that browser rule, CFP3 automatically allows browsers to connect to all non-privileged ports, including with http requests-which allows sites to bypass virus scanners. I have been using and recommending that rule all along, but we need to recognize that the security risk is there and that http is no longer restricted to the http ports which are normally also incorporated in our web virus scanners. Unless we incorporate ftp in SPI or change ask I don’t see a solution that avoids the risk and still provides the ftp functionality. CFP 3.0.16.295 WEB BROWSER RULES ALLOW AUTOMATICALLY HTTP REQUESTS THAT BYPASS WEB VIRUS’SPYWARE SCANNERS. But you can’t use passive ftp from your browser unless you accept that risk. 
I accept the risk; it is up to other users to understand the risk and make their choice. 
I used avast for a long time. That http scanner only scan connections to port 80 by default.
Http connections usually start on a >1023 port on the user side and use port 80 as a standard destination.
It is possible to run an http server on port 21 or 110. I guess it would be better to use web browser to do only plain http browsing.
It would still be possible to configure an external program to handle ftp requests.
Anyway this was what most users asked for. :-X
Avast realtime scanner or D+ should catch any “alien” code the moment it lands ;D
BTW, if you want to verify this: Try http://forums.comodo.com:1549/ . You won’t get an answer, because nobody is listening-site not available. But you won’t get a block either if you check your log.
Then try something like http://forums.comodo.com:738/ to verify that you should be getting block messages
But if the bad guys were listening on 1549 …
And, Gibran, getting the users to define an ftp client for their browsers seems a lot more difficult than fixing either SPI or ask. Opera is actually quite easy to set up with Filezilla as an FTP client, but FF and IE7 ??? I use Avast!, and have advised most users to list all of their http ports to be scanned in the Avast! configuration tab. But I don’t think it can handle 1025-65535. Especially when the FTP data packets are different. 
I think we need to warn users this might happen. And the avast! Standard Shield should also catch it, as well as the D+. But undoing the effort to limit the ports just to make things function seems like it should qualify as at least a design bug. Up to Melih whether/when he wants to fix these kind of things.
If we consider that a bad guy would be listening then also port 80 is insecure and we should configure V3 to ask for every connection so that some new script just slipped by will be unable to exploit internet explorer unfixed vulnerabilities.
If we consider hypothetical cases I guess that an user that is not able to configure what ftp client should handle his ftp requests he will not able to answer to the ask alerts properly or it will simply be bothered by those.
Assigning a policy to a program is an user choice and is also optional. If it is too much to suppose than and user is going to read the predefined policies before applying then the best thing to suggest would be to use a secure browser.
Anyway suggesting to change the default ftp client of a browser would require the same efforts than changing avast default webshield settings.
So I hope to have imagined most conceivable user skill level out there.
OK, the issue has been discussed and the users can decide if they care. And at least Opera has a simple workaround.