Source-Changes-HG archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[src/trunk]: src/gnu/dist/postfix not part of release 1.1.2



details:   https://anonhg.NetBSD.org/src/rev/d3d03132f9c1
branches:  trunk
changeset: 521660:d3d03132f9c1
user:      perry <perry%NetBSD.org@localhost>
date:      Sat Feb 02 23:27:32 2002 +0000

description:
not part of release 1.1.2

diffstat:

 gnu/dist/postfix/DB_README                                               |   68 -
 gnu/dist/postfix/DEBUG_README                                            |  153 ---
 gnu/dist/postfix/ETRN_README                                             |  117 --
 gnu/dist/postfix/FILTER_README                                           |  216 ----
 gnu/dist/postfix/INSTALL.sh                                              |  373 --------
 gnu/dist/postfix/LDAP_README                                             |  328 -------
 gnu/dist/postfix/LINUX_README                                            |   17 -
 gnu/dist/postfix/LMTP_README                                             |  466 ----------
 gnu/dist/postfix/MACOSX_README                                           |    2 -
 gnu/dist/postfix/MYSQL_README                                            |   92 -
 gnu/dist/postfix/PCRE_README                                             |   47 -
 gnu/dist/postfix/RESTRICTION_CLASS                                       |   24 -
 gnu/dist/postfix/SASL_README                                             |  206 ----
 gnu/dist/postfix/TODO                                                    |  160 ---
 gnu/dist/postfix/ULTRIX_README                                           |   34 -
 gnu/dist/postfix/UUCP_README                                             |    6 -
 gnu/dist/postfix/auxiliary/MacOSX/README.OSXPublicBeta                   |   31 -
 gnu/dist/postfix/auxiliary/MacOSX/darwin-Postfix/Postfix                 |   13 -
 gnu/dist/postfix/auxiliary/MacOSX/darwin-Postfix/StartupParameters.plist |   12 -
 gnu/dist/postfix/auxiliary/MacOSX/stash-sendmail                         |    6 -
 gnu/dist/postfix/conf/postfix-script-diff                                |   22 -
 gnu/dist/postfix/conf/postfix-script-nosgid                              |  273 -----
 gnu/dist/postfix/conf/postfix-script-sgid                                |  274 -----
 gnu/dist/postfix/conf/sample-pcre.cf                                     |   52 -
 gnu/dist/postfix/conf/sample-regexp.cf                                   |   21 -
 gnu/dist/postfix/src/global/mail_command_read.c                          |   69 -
 gnu/dist/postfix/src/global/mail_command_write.c                         |   82 -
 gnu/dist/postfix/src/global/mail_print.c                                 |  206 ----
 gnu/dist/postfix/src/global/mail_scan.c                                  |  272 -----
 gnu/dist/postfix/src/util/attr.c                                         |   78 -
 30 files changed, 0 insertions(+), 3720 deletions(-)

diffs (truncated from 3840 to 300 lines):

diff -r dc80da767ac0 -r d3d03132f9c1 gnu/dist/postfix/DB_README
--- a/gnu/dist/postfix/DB_README        Sat Feb 02 23:21:45 2002 +0000
+++ /dev/null   Thu Jan 01 00:00:00 1970 +0000
@@ -1,68 +0,0 @@
-Purpose of this document
-========================
-
-This document describes how to build Postfix with third-party
-Berkeley DB from www.sleepycat.com, or how to choose a specific
-Berkeley DB version when your system provides multiple implementations.
-
-Building Postfix with Sleepycat Berkeley DB
-===========================================
-
-Many commercial UNIXes ship without Berkeley DB support. Examples
-are Solaris, HP-UX, IRIX, UNIXWARE. In order to build Postfix with
-Berkeley DB support you need to download and install the source
-code from www.sleepycat.com.
-
-To build Postfix after you installed the Berkeley DB from Sleepycat,
-use something like:
-
-    % make tidy
-    % make makefiles CCARGS="-DHAS_DB -I/usr/local/BerkeleyDB.3.1/include" \
-       AUXLIBS="-L/usr/local/BerkeleyDB.3.1/lib -ldb"
-    % make
-
-The exact pathnames depend on the DB version that you installed.
-For example, Berkeley DB version 2 installs in /usr/local/BerkeleyDB.
-
-Beware, the file format produced by Berkeley DB version 1 is not
-compatible with that of versions 2 and 3 (versions 2 and 3 have
-the same format). If you switch between DB versions, then you may
-have to rebuild all your Postfix DB files.
-
-Building Postfix on BSD systems with a specific Berkeley DB version
-===================================================================
-
-Some BSD systems ship with multiple Berkeley DB implementations.
-Normally, Postfix builds with the default DB version that ships
-with the system.
-
-To build Postfix on BSD systems with a specific DB version, use a
-variant of the following commands:
-
-    % make tidy
-    % make makefiles CCARGS=-I/usr/include/db2 AUXLIBS=-ldb2
-    % make
-
-Beware, the file format produced by Berkeley DB version 1 is not
-compatible with that of versions 2 and 3 (versions 2 and 3 have
-the same format). If you switch between DB versions, then you may
-have to rebuild all your Postfix DB files.
-
-Building Postfix on Linux with a specific Berkeley DB version
-=============================================================
-
-Some Linux systems systems ship with multiple Berkeley DB
-implementations.  Normally, Postfix builds with the default DB
-version that ships with the system.
-
-On Linux, you need to edit the makedefs script in order to specify
-a non-default DB library.
-
-The reason is that the location of the default db.h include file
-changes randomly between vendors and between versions, so that
-Postfix has to choose the file for you.
-
-Beware, the file format produced by Berkeley DB version 1 is not
-compatible with that of versions 2 and 3 (versions 2 and 3 have
-the same format). If you switch between DB versions, then you may
-have to rebuild all your Postfix DB files.
diff -r dc80da767ac0 -r d3d03132f9c1 gnu/dist/postfix/DEBUG_README
--- a/gnu/dist/postfix/DEBUG_README     Sat Feb 02 23:21:45 2002 +0000
+++ /dev/null   Thu Jan 01 00:00:00 1970 +0000
@@ -1,153 +0,0 @@
-1 - Purpose of this document
-============================
-
-This document describes how to debug parts of the Postfix mail
-system, either by making the software log a lot of detail to the
-syslog daemon, or by running some daemon processes under control
-of an interactive debugger.
-
-2 - Verbose logging for specific SMTP connections
-=================================================
-
-In /etc/postfix/main.cf, list the remote site name or address in
-the "debug_peer_list" parameter. For example, in order to make the
-software log a lot of information to the syslog daemon for connections
-from or to the loopback interface:
-
-    debug_peer_list = 127.0.0.1
-
-You can specify one or more hosts, domains, addresses or net/masks.
-
-2b - Record the SMTP connection with a sniffer
-==============================================
-
-This example uses tcpdump. In order to record a conversation you
-need to specify a large enough buffer or else you will miss some
-or all of the packet payload.
-
-    tcpdump -w /file/name -s 2000 host hostname and port 25
-
-Run this for a while, stop with Ctrl-C when done. To view the data
-use a binary viewer, or use my tcpdumpx utility that is available
-from ftp://ftp.porcupine.org/pub/debugging.
-
-3 - Making Postfix daemon programs more verbose
-===============================================
-
-Append one or more -v options to selected daemon definitions in
-/etc/postfix/master.cf and type "postfix reload". This will cause
-a lot of activity to be logged to the syslog daemon.
-
-4 - Manually tracing a Postfix daemon process
-=============================================
-
-Some systems allow you to inspect a running process with a system
-call tracer. For example:
-
-       # trace -p process-id
-       # strace -p process-id
-       # truss -p process-id
-       # ktrace -p process-id
-
-See your system documentation for details.
-
-Tracing a running process can give valuable information about what
-a process is attempting to do. This is as much information as you
-can get without running an interactive debugger program, as described
-in a later section.
-
-5 - Automatically tracing a Postfix daemon process
-==================================================
-
-Postfix can attach a call tracer whenever a daemon process starts.
-
-Append a -D option to the suspect command in /etc/postfix/master.cf,
-for example:
-
-    smtp      inet  n       -       n       -       -       smtpd -D
-
-Edit the debugger_command definition in /etc/postfix/main.cf so
-that it invokes the call tracer of your choice, for example:
-
-    debugger_command =
-         PATH=/bin:/usr/bin:/usr/local/bin
-         (truss -p $process_id 2>&1 | logger -p mail.info) & sleep 5
-
-Instead of truss use trace or strace.
-
-Type "postfix reload" and watch the logfile.
-
-6 - Running daemon programs under an interactive debugger
-=========================================================
-
-Append a -D option to the suspect command in /etc/postfix/master.cf,
-for example:
-
-    smtp      inet  n       -       n       -       -       smtpd -D
-
-Edit the debugger_command definition in /etc/postfix/main.cf so
-that it invokes the debugger of your choice, for example:
-
-    debugger_command =
-         PATH=/usr/bin:/usr/X11R6/bin
-         xxgdb $daemon_directory/$process_name $process_id & sleep 5
-
-If you use xxgdb, be sure that gdb is in the command search path.
-
-Export XAUTHORITY so that X access control works, for example:
-
-    % setenv XAUTHORITY ~/.Xauthority
-
-Stop and start the Postfix system. 
-
-Whenever the suspect daemon process is started, a debugger window
-pops up and you can watch in detail what happens.
-
-7 - Unreasonable behavior
-=========================
-
-Sometimes the behavior exhibit by Postfix just does not match the
-source code. Why can a program deviate from the instructions given
-by its author? There are two possibilities.
-
-1 - The compiler has messed up.
-
-2 - The hardware has messed up.
-
-In both cases, the program being executed is not the program that
-was supposed to be executed, so anything can happen.
-
-There is a third possibility:
-
-3 - Bugs in system software (kernel or libraries).
-
-Hardware-related failures happen erratically, and they usually do
-not reproduce after power cycling and rebooting the system.  There's
-little I can do about bad hardware.  Be sure to use hardware that
-at the very least can detect memory errors. Otherwise, Postfix will
-just be a sitting duck waiting to be hit by a bit error. Critical
-systems deserve real hardware.
-
-When a compiler messes up, the problem can be reproduced whenever
-the resulting program is run. Compiler errors are most likely to
-happen in the code optimizer. If a problem is reproducible across
-power cycles and system reboots, it can be worthwhile to rebuild
-Postfix with optimization disabled, and to see if optimization
-makes a difference.
-
-In order to compile Postfix with optimizations turned off:
-
-    % make tidy
-    % make makefiles OPT=
-
-This produces a set of Makefiles that do not request compiler
-optimization. 
-
-Once the makefiles are set up, build the software:
-
-    % make
-    % su
-    # make install
-
-And see if the problem reproduces. If the problem goes away, talk
-to your vendor.
diff -r dc80da767ac0 -r d3d03132f9c1 gnu/dist/postfix/ETRN_README
--- a/gnu/dist/postfix/ETRN_README      Sat Feb 02 23:21:45 2002 +0000
+++ /dev/null   Thu Jan 01 00:00:00 1970 +0000
@@ -1,117 +0,0 @@
-Purpose of this document
-========================
-
-This document describes the purpose of the Postfix fast ETRN service,
-how the service works, and how it can be tested.
-
-Other documents with information on this subject:
-
-- conf/sample-flush.cf, sample configuration file
-- conf/main.cf, sample configuration file
-- flush(8), flush service implementation
-
-The Postfix fast ETRN service
-=============================
-
-The SMTP ETRN command was designed for sites that have intermittent
-Internet connectivity. With ETRN, a site can tell the mail server
-of its provider to "Please deliver all my mail now".
-
-Postfix versions before 20001005 implemented the ETRN command in
-a lame manner: they simply attempted to deliver all queued mail.
-This is slow on mail servers that queue mail for many customers.
-
-As of version 20001005, Postfix has a fast ETRN implementation that
-does not require Postfix to examine every queue file.  The command
-"sendmail -qR" is now implemented by sending an ETRN command to
-the local SMTP server.
-
-Postfix "fast ETRN/sendmail -qR" speeds up deliveries by attempting
-to deliver only mail that is queued for a given destination site.
-The old Postfix "slow ETRN" is still used as a fall-back method.
-
-How Postfix fast ETRN works
-===========================
-
-The "fast ETRN" service uses the new "flush" daemon which maintains
-per-destination logfiles of queued mail.  These logfiles are kept
-below /var/spool/postfix/flush. Each logfile is named after its
-destination domain name. Only destinations with syntactically valid
-domain names can have per-destination logfiles.
-
-The behavior of the new "flush" daemon is controlled by parameters
-in the main.cf configuration file.
-
-By default, Postfix "fast ETRN/sendmail -qR" service is available
-only for destinations that Postfix is willing to relay mail to:
-
-    fast_flush_domains = $relay_domains
-
-The "relay_domains" parameter specifies what destinations Postfix
-will relay to.  
-
-For destinations that are not eligible for the new "fast ETRN/sendmail
--qR" service, Postfix falls back to the old "slow ETRN" method
-which attempts to deliver all queued mail.
-
-To enable "fast ETRN/sendmail -qR" for some other destination, specify:
-
-    fast_flush_domains = $relay_domains, some.other.domain
-
-To disable "fast ETRN/sendmail -qR", so that Postfix always uses
-the old "slow ETRN" which delivers all queued mail, specify:
-
-    fast_flush_domains =
-
-Testing the fast ETRN service
-=============================



Home | Main Index | Thread Index | Old Index