Missed a typo "s/strenght/strength/"
On 01/25/20 14:12, Edgar Pettijohn wrote:
On 01/25/20 14:08, gil...@poolp.org wrote:
The diff reads ok but I wonder why you removed this sentence:
-No decision is ever taken by the report stream.
I think it made it a bit more clear that reporting is informative only.
I felt that the line stating it was a one-way stream covered it.
Mainly it just made me stumble on the line and have to reread it a
couple of times.
Edgar
diff --git a/smtpd/smtpd-filters.7 b/smtpd/smtpd-filters.7
index 1e1a27ef..bf563174 100644
--- a/smtpd/smtpd-filters.7
+++ b/smtpd/smtpd-filters.7
@@ -89,22 +89,21 @@ to inform
in real-time about events that are occurring in the daemon.
The report events do not expect an answer from
.Nm ,
-it is just meant to provide them with informations.
+it is just meant to provide them with information.
A filter should be able to replicate the
.Xr smtpd 8
-state for a session by gathering informations coming from report events.
-No decision is ever taken by the report stream.
+state for a session by gathering information coming from report events.
.Pp
The filter stream is a two-way stream which allows
.Xr smtpd 8
to query
.Nm
about what it should do with a session at a given phase.
-The filter requests expects an answer from
+The filter requests expect an answer from
.Nm ,
.Xr smtpd 8
will not let the session move forward until then.
-A decision must always be taken by the filter stream.
+A decision must always be made by the filter stream.
.Pp
It is sometimes possible to rely on filter requests to gather information,
but because a reponse is expected by
@@ -112,13 +111,13 @@ but because a reponse is expected by
this is more costly than using report events.
The correct pattern for writing filters is to use the report events to
create a local state for a session,
-then use filter requests to take decisions based on this state.
+then use filter requests to make decisions based on this state.
The only case when using filter request instead of report events is correct,
is when a decision is required for the filter request and there is no need for
more information than that of the event.
.Sh PROTOCOL
The protocol is straightforward,
-it consists of a human-readable line exchanges between
+it consists of human-readable line exchanges between
.Nm
and
.Xr smtpd 8
@@ -165,7 +164,7 @@ will be documented in the sections below.
.Sh CONFIGURATION
During the initial handshake,
.Xr smtpd 8
-will emit a serie of configuration keys and values.
+will emit a series of configuration keys and values.
The list is meant to be ignored by
.Nm
that do not require it and consumed gracefully by filters that do.
@@ -265,7 +264,7 @@ This event is generated upon successful negotiation of TLS.
.Pp
.Ar tls-string
contains a colon-separated list of TLS properties including the TLS version,
-the cipher suite used by the session and the cipher strenght in bits.
+the cipher suite used by the session and the cipher strength in bits.
.It Ic link-disconnect
This event is generated upon disconnection of the client.
.It Ic link-auth : Ar username Ar result
@@ -514,7 +513,7 @@
filter|0.5|1576146008.006103|smtp-in|data-line|7641df9771b4ed00|1ef1c203cc576e5d
filter|0.5|1576146008.006105|smtp-in|data-line|7641df9771b4ed00|1ef1c203cc576e5d|.
.Ed
.Pp
-They are expected to produce an output stream similarly terminate by a single
+They are expected to produce an output stream similarly terminated by a single
dot.
A filter may inject,
suppress,
