Adding upstream version 3.8.5.upstream/3.8.5

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 78 insertions, 0 deletions

diff --git a/README_FILES/PCRE_README b/README_FILES/PCRE_README
new file mode 100644
index 0000000..6dffb4b
--- /dev/null
+++ b/README_FILES/PCRE_README
@@ -0,0 +1,78 @@
+PPoossttffiixx PPCCRREE SSuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+PPCCRREE ((PPeerrll CCoommppaattiibbllee RReegguullaarr EExxpprreessssiioonnss)) mmaapp ssuuppppoorrtt
+
+The optional "pcre" map type allows you to specify regular expressions with the
+PERL style notation such as \s for space and \S for non-space. The main
+benefit, however, is that pcre lookups are often faster than regexp lookups.
+This is because the pcre implementation is often more efficient than the POSIX
+regular expression implementation that you find on many systems.
+
+A description of how to use pcre tables, including examples, is given in the
+pcre_table(5) manual page. Information about PCRE itself can be found at http:/
+/www.pcre.org/.
+
+UUssiinngg PPoossttffiixx ppaacckkaaggeess wwiitthh PPCCRREE ssuuppppoorrtt
+
+To use pcre with Debian GNU/Linux's Postfix, or with Fedora or RHEL Postfix,
+all you need is to install the postfix-pcre package and you're done. There is
+no need to recompile Postfix.
+
+BBuuiillddiinngg PPoossttffiixx ffrroomm ssoouurrccee wwiitthh PPCCRREE ssuuppppoorrtt
+
+These instructions assume that you build Postfix from source code as described
+in the INSTALL document.
+
+To build Postfix from source with pcre support, you need a pcre library.
+Install a vendor package, or download the source code from locations in https:/
+/www.pcre.org/ and build that yourself.
+
+Postfix can build with the pcre2 library or the legacy pcre library. It's
+probably easiest to let the Postfix build procedure pick one. The following
+commands will first discover if the pcre2 library is installed, and if that is
+not available, will discover if the legacy pcre library is installed.
+
+    $ make -f Makefile.init makefiles
+    $ make
+
+To build Postfix explicitly with a pcre2 library (Postfix 3.7 and later):
+
+    $ make -f Makefile.init makefiles \
+        "CCARGS=-DHAS_PCRE=2 `pcre2-config --cflags`" \
+        "AUXLIBS_PCRE=`pcre2-config --libs8`"
+    $ make
+
+To build Postfix explicitly with a legacy pcre library (all Postfix versions):
+
+    $ make -f Makefile.init makefiles \
+        "CCARGS=-DHAS_PCRE=1 `pcre-config --cflags`" \
+        "AUXLIBS_PCRE=`pcre-config --libs`"
+    $ make
+
+Postfix versions before 3.0 use AUXLIBS instead of AUXLIBS_PCRE. With Postfix
+3.0 and later, the old AUXLIBS variable still supports building a statically-
+loaded PCRE database client, but only the new AUXLIBS_PCRE variable supports
+building a dynamically-loaded or statically-loaded PCRE database client.
+
+    Failure to use the AUXLIBS_PCRE variable will defeat the purpose of dynamic
+    database client loading. Every Postfix executable file will have PCRE
+    library dependencies. And that was exactly what dynamic database client
+    loading was meant to avoid.
+
+TThhiinnggss ttoo kknnooww
+
+  * When Postfix searches a pcre: or regexp: lookup table, each pattern is
+    applied to the entire input string. Depending on the application, that
+    string is an entire client hostname, an entire client IP address, or an
+    entire mail address. Thus, no parent domain or parent network search is
+    done, "user@domain" mail addresses are not broken up into their user and
+    domain constituent parts, and "user+foo" is not broken up into user and
+    foo.
+
+  * Regular expression tables such as pcre: or regexp: are not allowed to do
+    $number substitution in lookup results that can be security sensitive:
+    currently, that restriction applies to the local aliases(5) database or the
+    virtual(8) delivery agent tables.
+