aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSergey Poznyakoff <gray@gnu.org.ua>2010-08-07 15:13:00 +0300
committerSergey Poznyakoff <gray@gnu.org.ua>2010-08-07 15:13:00 +0300
commita3180f2848c267e10531169de229f936faef3d91 (patch)
tree24cf0f77103574a365e9daff8d440ad6ee373d43
parentafe0fcc39eca699ce3536bdc497b0d07b123fcf5 (diff)
downloadmailfromd-release-7.0.tar.gz
mailfromd-release-7.0.tar.bz2
Version 7.0release-7.0
* NEWS, configure.ac: Update * doc/upgrade.texi: Update
-rw-r--r--NEWS65
-rw-r--r--configure.ac4
-rw-r--r--doc/upgrade.texi2
3 files changed, 36 insertions, 35 deletions
diff --git a/NEWS b/NEWS
index b2d364b4..e4265992 100644
--- a/NEWS
+++ b/NEWS
@@ -1,11 +1,11 @@
-Mailfromd NEWS -- history of user-visible changes. 2010-08-02
+Mailfromd NEWS -- history of user-visible changes. 2010-08-07
Copyright (C) 2005, 2006, 2007, 2008, 2009, 2010 Sergey Poznyakoff
See the end of file for copying conditions.
Please send Mailfromd bug reports to <bug-mailfromd@gnu.org.ua>
-Version 6.0.94 (Git)
+Version 7.0, 2010-08-07
* Incompatible changes
@@ -34,21 +34,21 @@ this verification yields a definite answer, that answer is stored
in the cache database and returned to the calling procedure as
usual. In that regard, this release works exactly as its predecessors
did. If, however, the verification is aborted due to a timeout,
-the caller procedure is returned an e_temp_failure exception, and
+the caller procedure is returned the e_temp_failure exception, and
the session is scheduled for processing by a callout server. The
latter processes the request using a set of `hard' timeouts,
which are normally much longer than `soft' ones (their default values
are those required by RFC 2822; see below for a detailed description).
This callout session runs independently of the milter session that
-initiated it. The milter session returns a temporary error to
-the sender, urging it to retry the connection later. In the meantime,
-the callout server has a chance to finish the requested sender
-verification and store its result in the cache database. When the
-sender retries the delivery, the milter server will obtain the already
-cached result from the database. If the callout server has not
-finished the request by the time the sender retries the connection,
-the latter is again returned a temporary error, and the process
-continues until the callout is finished.
+initiated it and which, having initiated the callout, returns a
+temporary error to the sender, urging it to retry the connection
+later. In the meantime, the callout server has a chance to finish the
+requested sender verification and store its result in the cache
+database. When the sender retries the delivery, the milter server
+will obtain the already cached result from the database. If the
+callout server has not finished the request by the time the sender
+retries the connection, the latter is again returned a temporary
+error, and the process continues until the callout is finished.
Milter servers are declared using the following configuration
statement:
@@ -84,21 +84,22 @@ statement:
* Timeout control for callout SMTP sessions
-Callout SMTP sessions initiated by polling functions, are controlled
+Callout SMTP sessions initiated by polling functions are controlled
by two sets of timeouts: `soft' and `hard'. Soft timeouts are used
by the mailfromd milter servers. Hard timeouts are used by callout
servers. When a soft timeout is exceeded, the calling procedure is
-delivered an e_temp_failure exception and the session is scheduled for
+delivered the e_temp_failure exception and the session is scheduled for
processing by a callout server. The latter re-runs the session using
hard timeouts. If a hard timeout is exceeded, the address is marked
as `not_found' and is stored in the cache database with that status.
Normally, soft timeouts are set to shorter values, suitable for use
-in MFL scripts. Hard timeouts are set to large values, as requested
-by RFC2822, which guarantee obtaining a definite answer (see below
-for the default values).
+in MFL scripts without disturbing the calling SMTP session. Hard
+timeouts are set to large values, as requested by RFC2822, which
+guarantee obtaining a definite answer (see below for the default
+values).
-Individual timeouts may be set in the configuration file, using the
+Individual timeouts may be set in the configuration file using the
following statement:
smtp-timeout [soft | hard] {
@@ -179,9 +180,8 @@ identifier may then be used in `catch' and `throw' statements, e.g.:
throw myerror "My error encountered"
-For a detailed discussion, see the manual, subsection 4.18.2
+For a detailed discussion, see the manual, subsection 4.19.2
"User-defined Exceptions".
-FIXME: Before release, check if the subsection number is right.
** The try-catch construct
@@ -208,16 +208,15 @@ STMTLIST-2.
The `try-catch' construct allows a better and more flexible error
recovery.
-For a detailed discussion, see the manual, subsection 4.18.3
+For a detailed discussion, see the manual, subsection 4.19.3
"Exception Handling".
-FIXME: Before release, check if the subsection number is right.
** Handling of stderr in open("|...")
-If open call is used to start external program (i.e. its argument
-begins with a `|' or `|&'), the standard error of the program is
-closed prior to starting it. Special constructs are provided for
-redirecting it to an output file or syslog:
+If the open function is used to start an external program (i.e. the
+argument to open() begins with a `|' or `|&'), the standard error of
+the program is closed prior to starting it. The following special
+constructs are provided for redirecting it to an output file or syslog:
- "|2>null: COMMAND"
Standard error is redirected to /dev/null.
@@ -250,14 +249,13 @@ results in the following warning message:
message modification commands to be ignored; call mmq_purge() prior
to `accept', to suppress this warning
-It is only a warning, the `accept' action itself is, of course, honored.
+It is only a warning and the `accept' action itself is, of course, honored.
If you see this diagnostics in your log, do the following:
- if the behavior was intended, call mmq_purge, as suggested (see
below for a description of this function);
- - if it was not, read the manual, subsection `4.12.1.8 Message
- Modification Queue', for information on how to handle it.
- FIXME: section number is subject to change.
+ - if it was not, read the manual, section 5.8, "Message
+ Modification Queue", for information on how to handle it.
** #pragma miltermacros
@@ -268,7 +266,10 @@ each handler, i.e. when at least one of the handlers:
- calls functions that reference MTA macros;
- refers to macros via macro_defined() and getmacro() functions.
-
+
+See the manual, subsection 4.2.5, "Pragma miltermacros", for a
+detailed description.
+
** MFL functions
*** progress
@@ -311,7 +312,7 @@ supplied module names.
The function `mmq_purge' purges internal message modification queue.
This undoes the effect of the following functions, if they had been
called previously: rcpt_add, rcpt_delete, header_add, header_insert,
-header_delete, header_replace, replbody, quarantine
+header_delete, header_replace, replbody, quarantine.
** New built-in constant `__git__'.
diff --git a/configure.ac b/configure.ac
index 7d72b45b..dccccfbf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -15,9 +15,9 @@
# along with this program. If not, see <http://www.gnu.org/licenses/>.
AC_PREREQ(2.63)
-m4_define([MF_VERSION_MAJOR], 6)
+m4_define([MF_VERSION_MAJOR], 7)
m4_define([MF_VERSION_MINOR], 0)
-m4_define([MF_VERSION_PATCH], 94)
+dnl m4_define([MF_VERSION_PATCH], 0)
AC_INIT([mailfromd],
MF_VERSION_MAJOR.MF_VERSION_MINOR[]m4_ifdef([MF_VERSION_PATCH],.MF_VERSION_PATCH),
[bug-mailfromd@gnu.org.ua])
diff --git a/doc/upgrade.texi b/doc/upgrade.texi
index 3e6d74d3..f20ff8d7 100644
--- a/doc/upgrade.texi
+++ b/doc/upgrade.texi
@@ -78,7 +78,7 @@ particular, it is worth noticing that the @code{open} function, when
opening a pipe to or from a command, provides a way to control where
the command's standard error would go (@pxref{open, standard error}).
- The @code{accept} function (or action) issues a warning if it would
+ The @code{accept} function (or action) issues a warning if its use would
cancel any modifications to the message applied by, e.g.,
@code{header_add} and similar functions. @xref{Message modification
queue}, for a detailed discussion of this feature.

Return to:

Send suggestions and report system problems to the System administrator.