Each supported protocol may implement available content filters differently. Not all filtering capabilities are supported for each protocol.
This topic contains:
The HTTP protocol supports all content filtering features. With HTTP, the content filter remains in the gateway, checking every request and response between the HTTP client and server.
If an HTTP request is dropped due to content filtering, the client receives a response such as:
- <custom drop message/user-configured drop message>.<src_port><dst_ip>:<dst_port>Download
request was dropped due to <reason>
Therefore, a message may appear as follows:
- Juniper Networks Firewall Content Filtering blocked request.
5.5.5.1:80->4.4.4.1:55247 Download request was dropped due to file
extension block list
The FTP protocol does not support all content filtering features. It supports only the following: Block Extension List and Protocol Command Block List.
When content filtering blocks an FTP request, the following response is sent through the control channel:
- 550 <src_ip>:<src_port>-<dst_ip>:<dst_port><custom
drop message/user-configured drop message> for Content Filtering
file extension block list.>
Therefore, a message may appear as follows:
- 550 5.5.5.1:21->4.4.4.1:45237 Requested action not taken
and the request is dropped for Content Filtering file extension block
list
E-mail protocols (SMTP, IMAP, POP3) have limited content filtering support for the following features: Block Extension List, Protocol Command Block List, and MIME Pattern Filtering. Support is limited for e-mail protocols for the following reasons:
- content-filtering {
-
- profile <name> {
-
- permit-command <cmd-list>
- block-command <cmd-list>
- block-extension <file-ext-list>
-
- block-mime {
-
- list <mime-list>
- exception <ex-mime-list>
- }
-
- block-content-type {
-
- activex
- java-applet
- exe
- zip
- http-cookie
- }
-
- notification-options {
-
- type { message }
- notify-mail-sender
- custom-message <msg>
- }
- }
- traceoptions {
-
- flag {
-
- all
- basic
- detail
- }
- }
- }
