Allowing or Denying the X-Forwarded-For header to be followed to
	find the original source of a request.

	Requests may pass through a chain of several other proxies
	before reaching us.  The X-Forwarded-For header will contain a
	comma-separated list of the IP addresses in the chain, with the
	rightmost address being the most recent.

	If a request reaches us from a source that is allowed by this
	configuration item, then we consult the X-Forwarded-For header
	to see where that host received the request from.  If the
	X-Forwarded-For header contains multiple addresses, we continue
	backtracking until we reach an address for which we are not allowed
	to follow the X-Forwarded-For header, or until we reach the first
	address in the list. For the purpose of ACL used in the
	follow_x_forwarded_for directive the src ACL type always matches
	the address we are testing and srcdomain matches its rDNS.

	The end result of this process is an IP address that we will
	refer to as the indirect client address.  This address may
	be treated as the client address for access control, ICAP, delay
	pools and logging, depending on the acl_uses_indirect_client,
	icap_uses_indirect_client, delay_pool_uses_indirect_client, 
	log_uses_indirect_client and tproxy_uses_indirect_client options.

	This clause only supports fast acl types.
	See http://wiki.squid-cache.org/SquidFaq/SquidAcl for details.

	SECURITY CONSIDERATIONS:

		Any host for which we follow the X-Forwarded-For header
		can place incorrect information in the header, and Squid
		will use the incorrect information as if it were the
		source address of the request.  This may enable remote
		hosts to bypass any access control restrictions that are
		based on the client's source addresses.

	For example:

		acl localhost src 127.0.0.1
		acl my_other_proxy srcdomain .proxy.example.com
		follow_x_forwarded_for allow localhost
		follow_x_forwarded_for allow my_other_proxy