#++
# 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
#--
