#++
# NAME
#	socketmap_table 5
# SUMMARY
#	Postfix socketmap table lookup client
# SYNOPSIS
#	\fBpostmap -q "\fIstring\fB" socketmap:inet:\fIhost\fB:\fIport\fB:\fIname\fR
# .br
#	\fBpostmap -q "\fIstring\fB" socketmap:unix:\fIpathname\fB:\fIname\fR
#
#	\fBpostmap -q - socketmap:inet:\fIhost\fB:\fIport\fB:\fIname\fB <\fIinputfile\fR
# .br
#	\fBpostmap -q - socketmap:unix:\fIpathname\fB:\fIname\fB <\fIinputfile\fR
# DESCRIPTION
#	The Postfix mail system uses optional tables for address
#	rewriting, mail routing or policy lookup.
#
#	The Postfix socketmap client expects TCP endpoint names of
#	the form \fBinet:\fIhost\fB:\fIport\fB:\fIname\fR, or
#	UNIX-domain endpoints of the form \fBunix:\fIpathname\fB:\fIname\fR.
#	In both cases, \fIname\fR specifies the name field in a
#	socketmap client request (see "REQUEST FORMAT" below).
# PROTOCOL
# .ad
# .fi
#	Socketmaps use a simple protocol: the client sends one
#	request, and the server sends one reply.  Each request and
#	each reply are sent as one netstring object.
# REQUEST FORMAT
# .ad
# .fi
#	The socketmap protocol supports only the lookup request.
#	The request has the following form:
#
# .IP "\fB\fIname\fB <space> \fIkey\fR"
#	Search the named socketmap for the specified key. 
# .PP
#	Postfix will not generate partial search keys such as domain
#	names without one or more subdomains, network addresses
#	without one or more least-significant octets, or email
#	addresses without the localpart, address extension or domain
#	portion. This behavior is also found with cidr:, pcre:, and
#	regexp: tables.
# REPLY FORMAT
# .ad
# .fi
#	Replies must have the following form:
# .IP "\fBOK <space> \fIdata\fR"
#	The requested data was found.
# .IP "\fBNOTFOUND <space>"
#	The requested data was not found.
# .IP "\fBTEMP <space> \fIreason\fR"
# .IP "\fBTIMEOUT <space> \fIreason\fR"
# .IP "\fBPERM <space> \fIreason\fR"
#	The request failed. The reason, if non-empty, is descriptive
#	text.
# PROTOCOL LIMITS
# .ad
# .fi
#	The Postfix socketmap client requires that replies are no
#	longer than 100000 bytes (not including the netstring
#	encapsulation). This limit can be changed with the
#	socketmap_max_reply_size configuration parameter (Postfix 3.10
#	and later).
#
#	The Postfix socketmap client enforces a 100s time limit to
#	connect to a socketmap server, to send a request, and to receive
#	a reply. It closes an idle connection after 10s, and closes
#	an active connection after 100s. These limits are not (yet)
#	configurable.
# SECURITY
# .ad
# .fi
#	This map cannot be used for security-sensitive information,
#	because neither the connection nor the server are authenticated.
# CONFIGURATION PARAMETERS
# .ad
# .fi
# .IP "\fBsocketmap_max_reply_size (100000)\fR"
#	The maximum allowed reply size from a socketmap server, not
#	including the netstring encapsulation.
# SEE ALSO
#	https://cr.yp.to/proto/netstrings.txt, netstring definition
#	postconf(1), Postfix supported lookup tables
#	postmap(1), Postfix lookup table manager
#	regexp_table(5), format of regular expression tables
#	pcre_table(5), format of PCRE tables
#	cidr_table(5), format of CIDR tables
# README FILES
# .ad
# .fi
#	Use "\fBpostconf readme_directory\fR" or
#	"\fBpostconf html_directory\fR" to locate this information.
# .na
# .nf
#	DATABASE_README, Postfix lookup table overview
# BUGS
#	The protocol time limits are not yet configurable.
# LICENSE
# .ad
# .fi
#	The Secure Mailer license must be distributed with this software.
# HISTORY
#	Socketmap support was introduced with Postfix version 2.10.
#
#	The socketmap protocol was published with Sendmail v8.13.
# AUTHOR(S)
#	Wietse Venema
#	IBM T.J. Watson Research
#	P.O. Box 704
#	Yorktown Heights, NY 10598, USA
#
#	Wietse Venema
#	Google, Inc.
#	111 8th Avenue
#	New York, NY 10011, USA
#
#	Wietse Venema
#	porcupine.org
#--

