Cleanup: a few remaining pre-ANSI C function definitions
in the lowest-level Postfix code. Files: util/binhash.c,
- util/close_on_exec.c, util/non_blocking.c.
+ util/close_on_exec.c, util/non_blocking.c, util/ring.c.
+
+20250130
+
+ Updated the TLSRPT_README introduction, github info, and
+ build instructions. File: proto/TLSRPT_README.html.
+
+20250131
+
+ Debug: verbose logging for the tlsrpt_wrapper functions.
+ File: tls/tlsrpt_wrapper.c.
report those summaries via email to the specified address. Instead of mailto:,
a policy may specify an https: destination.
-The high-level diagram shows how Postfix reports summaries to domains that
-publish a TLSRPT policy.
+The high-level diagram below shows how TLS handshake success and failure events
+from Postfix are collected and processed into daily summary reports.
- Postfix SMTP and TLSRPT client TLSRPT summary Email or HTTP
- TLS client --> library --> generator --> delivery
- engines
-
-When Postfix TLSRPT support is enabled (with "smtp_tlsrpt_enable = yes"):
+ Postfix SMTP and TLSRPT client TLSRPT collector, Email or HTTP
+ TLS client engines -> library (linked -> fetcher, and -> delivery
+ into Postfix) summary generator
* The Postfix SMTP and TLS client engines will generate a "success" or
"failure" event for each TLS handshake,
* They will pass those events to an in-process TLSRPT client library that
sends data over a local socket to
- * A TLSRPT report generator that produces daily summary reports.
+ * A local TLSRPT collector that runs on each Postfix machine. A TLSRPT
+ fetcher gathers information from individual collectors, and a central
+ TLSRPT report generator produces daily summary reports.
-The TLSRPT client library and report generator are maintained by sys4.
+The TLSRPT client library, and the infrastructure to collect, fetch, and report
+TLSRPT information are maintained by sys4 at https://github.com/sys4/libtlsrpt
+and https://github.com/sys4/tlsrpt-reporter, respectively.
The Postfix implementation supports both DANE (Postfix built-in) and MTA-STS
(through an smtp_tls_policy_maps plug-in).
in the INSTALL document. Some modification may be required if you build Postfix
from a vendor-specific source package.
-The Postfix TLSRPT client builds on a TLSRPT client library whose source code
-can be obtained from:
+The Postfix TLSRPT client builds on a TLSRPT library which may be available as
+a built package (rpm, deb, etc.), or which you can build from source code from:
- https://github.com/sys4/tlsrpt
+ https://github.com/sys4/libtlsrpt
The library is typically installed as a header file in /usr/local/include/
tlsrpt.h and an object library in /usr/local/lib/libtlsrpt.a or /usr/local/lib/
libtlsrpt.so. The actual pathnames will depend on OS platform conventions.
In order to build Postfix with TLSRPT support, you will need to add compiler
-options -DUSE_TLSRPT (to build with TLSRPT support), and -I (with the directory
+options -DUSE_TLSRPT (to build with TLSRPT support) and -I (with the directory
containing the tlsrpt.h header file), and you will need to add linker options
to link with the TLSRPT client library, for example:
make -f Makefile.init makefiles \
"CCARGS=-DUSE_TLSRPT -I/usr/local/include" \
- "AUXLIBS=-L/usr/local/lib -ltlsrpt"
+ "AUXLIBS=-L/usr/local/lib -Wl,-rpath,/usr/local/lib -ltlsrpt"
+
+(On Solaris systems you may need to use "-Wl,-R" instead of "-Wl,-rpath".)
Then, just run 'make'.
Note: if your build command line already has CCARGS or AUXLIBS settings,
then simply append the above settings to the existing CCARGS or AUXLIBS
- values.
+ values:
- make -f Makefile.init makefiles \
- "CCARGS=existing settings... -DUSE_TLSRPT -I/usr/local/include" \
- "AUXLIBS=existing settings... -L/usr/local/lib -ltlsrpt"
+ make -f Makefile.init makefiles \
+ "CCARGS=... -DUSE_TLSRPT -I/usr/local/include" \
+ "AUXLIBS=... -L/usr/local/lib -Wl,-rpath,/usr/local/lib -ltlsrpt"
T\bTu\bur\brn\bni\bin\bng\bg o\bon\bn T\bTL\bLS\bSR\bRP\bPT\bT
main.cf like this:
smtp_tlsrpt_enable = yes
- smtp_tlsrpt_socket_name = /path/to/socket
+ smtp_tlsrpt_socket_name = path/to/socket
-The smtp_tlsrpt_socket_name parameter specifies an absolute pathname, or a
-pathname that is relative to $queue_directory.
+The smtp_tlsrpt_socket_name parameter specifies either an absolute pathname, or
+a pathname that is relative to $queue_directory.
- Note: the recommended socket location is still to be determined. A good
- socket location would be under the Postfix queue directory, for example:
+Notes:
+
+ * The recommended socket location is still to be determined. A good socket
+ location would be under the Postfix queue directory, for example:
"smtp_tlsrpt_socket_name = run/tlsrpt/tlsrpt.sock". The advantage of using
a relative name is that it will work equally well whether or not Postfix
chroot is turned on.
-Do not specify a location under a directory such as private or public that is
-already used by Postfix programs. Only Postfix programs should create sockets
-there.
+ * Regardless of whether Postfix chroot is enabled, the TLSRPT receiver
+ (tlsrpt_collectd) will need to be configured with the socket's absolute
+ pathname.
+
+ * Do not specify a TLSRPT socket location under a Postfix socket directory
+ such as private or public. Only Postfix programs should create sockets
+ there.
+
+For details on how to run the TLSRPT collection and reporting infrastructure,
+see the documentation at https://github.com/sys4/tlsrpt-reporter.
T\bTL\bLS\bSR\bRP\bPT\bT S\bSt\bta\bat\btu\bus\bs l\blo\bog\bgg\bgi\bin\bng\bg
D\bDe\bel\bli\biv\bve\ber\bri\bin\bng\bg T\bTL\bLS\bSR\bRP\bPT\bT s\bsu\bum\bmm\bma\bar\bri\bie\bes\bs v\bvi\bia\ba e\bem\bma\bai\bil\bl
RFC 8460 Section 3 specifies that an MTA must not enforce TLS security when
-sending failure reports via email. However, Postfix currently has no way to
-request that TLS enforcement will be disabled when submitting an email message.
+sending failure reports via email.
Options:
- * Specify the "T\bTL\bLS\bS-\b-R\bRe\beq\bqu\bui\bir\bre\bed\bd:\b: n\bno\bo" message header, defined in RFC 8689, to
- reduce the TLS security level to "m\bma\bay\by" (that is, do not verify remote SMTP
- server certificates, and fall back to plaintext if TLS is unavailable).
+ * In an email report, specify the "T\bTL\bLS\bS-\b-R\bRe\beq\bqu\bui\bir\bre\bed\bd:\b: n\bno\bo" message header, defined
+ in RFC 8689, to reduce the Postfix SMTP client TLS security level to "m\bma\bay\by"
+ (that is, do not verify remote SMTP server certificates, and fall back to
+ plaintext if TLS is unavailable).
- This feature is available in Postfix 3.10 and later.
+ This feature is available in Postfix 3.10 and later. If your outbound MTAs
+ run an older version, you can use one of the options described below.
* Do nothing. When TLS security enforcement is required but fails, a TLSRPT
summary message will be delayed until the problem is addressed, or until
real-time monitoring service; it takes on average 12 hours before a failure
is reported through TLSRPT.
- * Exclude the sender of TLSRPT summaries from TLS security enforcement.
- Implement the configuration below on outbound MTA instances (replace
- noreply-smtp-tls-reporting@example.com with your actual report generator's
- sender address):
+ * On outbound MTAs that don't support the "T\bTL\bLS\bS-\b-R\bRe\beq\bqu\bui\bir\bre\bed\bd:\b: n\bno\bo" header feature
+ (such as Postfix 3.9 and earlier), disable TLS security enforcement for the
+ sender of TLSRPT summaries. Implement the configuration below on outbound
+ MTA instances (replace noreply-smtp-tls-reporting@example.com with your
+ actual report generator's sender address):
/etc/postfix/main.cf:
# Limitation: this setting is overruled with transport_maps.
specified address. Instead of <tt>mailto:</tt>, a policy may specify an
<tt>https:</tt> destination. </p>
-<p> The high-level diagram shows how Postfix reports summaries to
-domains that publish a TLSRPT policy.
+<p> The high-level diagram below shows how TLS handshake success
+and failure events from Postfix are collected and processed into
+daily summary reports. </p>
<blockquote>
<table>
-<tr> <td align="center" bgcolor="#f0f0ff"> Postfix SMTP and<br> TLS
-client engines </td> <td> <tt> --> </tt> </td>
+<tr> <td align="center" bgcolor="#f0f0ff"> Postfix SMTP and TLS
+client engines </td> <td> <tt> → </tt> </td>
-<td align="center" bgcolor="#f0f0ff"> TLSRPT client <br> library
-</td> <td> <tt> --> </tt> </td>
+<td align="center" bgcolor="#f0f0ff"> <a
+href="https://github.com/sys4/libtlsrpt">TLSRPT client library </a>
+(linked into Postfix) </td> <td> <tt> → </tt> </td>
-<td align="center" bgcolor="#f0f0ff"> TLSRPT summary <br> generator
-</td> <td> <tt> --> </tt> </td>
+<td align="center" bgcolor="#f0f0ff"> <a
+href="https://github.com/sys4/tlsrpt-reporter">TLSRPT collector,
+fetcher, and summary generator</a> </td> <td> <tt> → </tt>
+</td>
-<td align="center" bgcolor="#f0f0ff"> Email or HTTP <br> delivery
-</td> </tr>
+<td align="center" bgcolor="#f0f0ff"> Email or HTTP delivery </td>
+</tr>
</table>
</blockquote>
-<p> When Postfix TLSRPT support is enabled (with "<a href="postconf.5.html#smtp_tlsrpt_enable">smtp_tlsrpt_enable</a>
-= yes"): </p>
-
<ul>
<li> <p> The Postfix SMTP and TLS client engines will generate a
<li> <p> They will pass those events to an in-process TLSRPT client
library that sends data over a local socket to </p>
-<li> <p> A TLSRPT report generator that produces daily summary
-reports. </p>
+<li> <p> A local TLSRPT collector that runs on each Postfix machine.
+A TLSRPT fetcher gathers information from individual collectors,
+and a central TLSRPT report generator produces daily summary reports.
+</p>
</ul>
-<p> The TLSRPT client library and report generator are maintained
-by sys4. </p>
+<p> The TLSRPT client library, and the infrastructure to collect,
+fetch, and report TLSRPT information are maintained by sys4 at
+<a href="https://github.com/sys4/libtlsrpt">https://github.com/sys4/libtlsrpt</a> and
+<a href="https://github.com/sys4/tlsrpt-reporter">https://github.com/sys4/tlsrpt-reporter</a>, respectively. </p>
<p> The Postfix implementation supports both DANE (Postfix built-in)
-and MTA-STS (through an <a href="postconf.5.html#smtp_tls_policy_maps">smtp_tls_policy_maps</a> plug-in).
-</p>
+and MTA-STS (through an <a href="postconf.5.html#smtp_tls_policy_maps">smtp_tls_policy_maps</a> plug-in). </p>
<p> The Postfix <a href="smtp.8.html">smtp(8)</a> client process implements the SMTP client
engine. With "<a href="postconf.5.html#smtp_tls_connection_reuse">smtp_tls_connection_reuse</a> = no", the <a href="smtp.8.html">smtp(8)</a> client
be required if you build Postfix from a vendor-specific source
package. </p>
-<p> The Postfix TLSRPT client builds on a TLSRPT client library
-whose source code can be obtained from: </p>
+<p> The Postfix TLSRPT client builds on a TLSRPT library which may
+be available as a built package (rpm, deb, etc.), or which you can
+build from source code from: </p>
<blockquote>
- <p> <a href="https://github.com/sys4/tlsrpt">https://github.com/sys4/tlsrpt</a> </p>
+<p> <a href="https://github.com/sys4/libtlsrpt">https://github.com/sys4/libtlsrpt</a> </p>
</blockquote>
<p> The library is typically installed as a header file in
<p> In order to build Postfix with TLSRPT support, you will need
to add compiler options <tt>-DUSE_TLSRPT</tt> (to build with TLSRPT
-support), and <tt>-I</tt> (with the directory containing the tlsrpt.h
+support) and <tt>-I</tt> (with the directory containing the tlsrpt.h
header file), and you will need to add linker options to link with
the TLSRPT client library, for example: </p>
<pre>
make -f Makefile.init makefiles \
"CCARGS=-DUSE_TLSRPT -I/usr/local/include" \
- "AUXLIBS=-L/usr/local/lib -ltlsrpt"
+ "AUXLIBS=-L/usr/local/lib -Wl,-rpath,/usr/local/lib -ltlsrpt"
</pre>
</blockquote>
+<p> (On Solaris systems you may need to use "<tt>-Wl,-R</tt>" instead
+of "<tt>-Wl,-rpath</tt>".) </p>
+
<p> Then, just run 'make'. </p>
<blockquote>
<p> Note: if your build command line already has CCARGS or AUXLIBS
settings, then simply append the above settings to the existing CCARGS
-or AUXLIBS values. </p>
+or AUXLIBS values: </p>
-<blockquote>
<pre>
make -f Makefile.init makefiles \
- "CCARGS=<i>existing settings...</i> -DUSE_TLSRPT -I/usr/local/include" \
- "AUXLIBS=<i>existing settings...</i> -L/usr/local/lib -ltlsrpt"
+ "CCARGS=... -DUSE_TLSRPT -I/usr/local/include" \
+ "AUXLIBS=... -L/usr/local/lib -Wl,-rpath,/usr/local/lib -ltlsrpt"
</pre>
</blockquote>
-</blockquote>
-
<h2> <a name="using"> Turning on TLSRPT </a> </h2>
<p> After installing Postfix TLSRPT support, you can enable TLSRPT
<blockquote>
<pre>
<a href="postconf.5.html#smtp_tlsrpt_enable">smtp_tlsrpt_enable</a> = yes
-<a href="postconf.5.html#smtp_tlsrpt_socket_name">smtp_tlsrpt_socket_name</a> = /path/to/socket
+<a href="postconf.5.html#smtp_tlsrpt_socket_name">smtp_tlsrpt_socket_name</a> = path/to/socket
</pre>
</blockquote>
-<p> The <a href="postconf.5.html#smtp_tlsrpt_socket_name">smtp_tlsrpt_socket_name</a> parameter specifies an absolute
-pathname, or a pathname that is relative to $<a href="postconf.5.html#queue_directory">queue_directory</a>. </p>
+<p> The <a href="postconf.5.html#smtp_tlsrpt_socket_name">smtp_tlsrpt_socket_name</a> parameter specifies either an
+absolute pathname, or a pathname that is relative to $<a href="postconf.5.html#queue_directory">queue_directory</a>.
+</p>
+
+<p> Notes: </p>
-<blockquote>
+<ul>
-<p> Note: the recommended socket location is still to be determined.
+<li> <p> The recommended socket location is still to be determined.
A good socket location would be under the Postfix queue directory,
for example: "<a href="postconf.5.html#smtp_tlsrpt_socket_name">smtp_tlsrpt_socket_name</a> = run/tlsrpt/tlsrpt.sock".
The advantage of using a relative name is that it will work equally
well whether or not Postfix chroot is turned on. </p>
-</blockquote>
+<li> <p> Regardless of whether Postfix chroot is enabled, the TLSRPT
+receiver (<tt>tlsrpt_collectd</tt>) will need to be configured with
+the socket's absolute pathname. </p>
-<p> Do not specify a location under a directory such as <tt>private</tt>
-or <tt>public</tt> that is already used by Postfix programs. Only Postfix
+<li> <p> Do not specify a TLSRPT socket location under a Postfix socket
+directory such as <tt>private</tt> or <tt>public</tt>. Only Postfix
programs should create sockets there. </p>
+</ul>
+
+<p> For details on how to run the TLSRPT collection and reporting
+infrastructure, see the documentation at
+<a href="https://github.com/sys4/tlsrpt-reporter">https://github.com/sys4/tlsrpt-reporter</a>.
+
<h2> <a name="logging"> TLSRPT Status logging </a> </h2>
<p> With TLSRPT support turned on, the Postfix TLSRPT client will
<p> <a href="https://datatracker.ietf.org/doc/html/rfc8460#section-3">RFC
8460 Section 3</a> specifies that an MTA must not enforce TLS
-security when sending failure reports via email. However, Postfix
-currently has no way to request that TLS enforcement will be disabled
-when submitting an email message. </p>
+security when sending failure reports via email. </p>
<p> Options:
<ul>
-<li> <p> Specify the "<b>TLS-Required: no</b>" message header,
-defined in <a href="https://tools.ietf.org/html/rfc8689">RFC 8689</a>, to reduce the TLS security level to "<b>may</b>"
-(that is, do not verify remote SMTP server certificates, and fall
-back to plaintext if TLS is unavailable). <br> <br> This feature
-is available in Postfix 3.10 and later. </p>
+<li> <p> In an email report, specify the "<b>TLS-Required: no</b>"
+message header,
+defined in <a href="https://tools.ietf.org/html/rfc8689">RFC 8689</a>, to reduce the Postfix SMTP client TLS security
+level to "<b>may</b>" (that is, do not verify remote SMTP server
+certificates, and fall back to plaintext if TLS is unavailable).
+<br> <br> This feature is available in Postfix 3.10 and later. If
+your outbound MTAs run an older version, you can use one of the
+options described below. </p>
<li> <p> Do nothing. When TLS security enforcement is required but
fails, a TLSRPT summary message will be delayed
monitoring service; it takes on average 12 hours before a failure
is reported through TLSRPT. </p>
-<li> <p> Exclude the sender of TLSRPT summaries from TLS security
-enforcement.
+<li> <p> On outbound MTAs that don't support the "<b>TLS-Required:
+no</b>" header feature (such as Postfix 3.9 and earlier), disable
+TLS security enforcement for the sender of TLSRPT summaries.
Implement the configuration below on outbound MTA instances (replace
noreply-smtp-tls-reporting@example.com with your actual report
generator's sender address): </p>
specified address. Instead of <tt>mailto:</tt>, a policy may specify an
<tt>https:</tt> destination. </p>
-<p> The high-level diagram shows how Postfix reports summaries to
-domains that publish a TLSRPT policy.
+<p> The high-level diagram below shows how TLS handshake success
+and failure events from Postfix are collected and processed into
+daily summary reports. </p>
<blockquote>
<table>
-<tr> <td align="center" bgcolor="#f0f0ff"> Postfix SMTP and<br> TLS
-client engines </td> <td> <tt> --> </tt> </td>
+<tr> <td align="center" bgcolor="#f0f0ff"> Postfix SMTP and TLS
+client engines </td> <td> <tt> → </tt> </td>
-<td align="center" bgcolor="#f0f0ff"> TLSRPT client <br> library
-</td> <td> <tt> --> </tt> </td>
+<td align="center" bgcolor="#f0f0ff"> <a
+href="https://github.com/sys4/libtlsrpt">TLSRPT client library </a>
+(linked into Postfix) </td> <td> <tt> → </tt> </td>
-<td align="center" bgcolor="#f0f0ff"> TLSRPT summary <br> generator
-</td> <td> <tt> --> </tt> </td>
+<td align="center" bgcolor="#f0f0ff"> <a
+href="https://github.com/sys4/tlsrpt-reporter">TLSRPT collector,
+fetcher, and summary generator</a> </td> <td> <tt> → </tt>
+</td>
-<td align="center" bgcolor="#f0f0ff"> Email or HTTP <br> delivery
-</td> </tr>
+<td align="center" bgcolor="#f0f0ff"> Email or HTTP delivery </td>
+</tr>
</table>
</blockquote>
-<p> When Postfix TLSRPT support is enabled (with "smtp_tlsrpt_enable
-= yes"): </p>
-
<ul>
<li> <p> The Postfix SMTP and TLS client engines will generate a
<li> <p> They will pass those events to an in-process TLSRPT client
library that sends data over a local socket to </p>
-<li> <p> A TLSRPT report generator that produces daily summary
-reports. </p>
+<li> <p> A local TLSRPT collector that runs on each Postfix machine.
+A TLSRPT fetcher gathers information from individual collectors,
+and a central TLSRPT report generator produces daily summary reports.
+</p>
</ul>
-<p> The TLSRPT client library and report generator are maintained
-by sys4. </p>
+<p> The TLSRPT client library, and the infrastructure to collect,
+fetch, and report TLSRPT information are maintained by sys4 at
+https://github.com/sys4/libtlsrpt and
+https://github.com/sys4/tlsrpt-reporter, respectively. </p>
<p> The Postfix implementation supports both DANE (Postfix built-in)
-and MTA-STS (through an smtp_tls_policy_maps plug-in).
-</p>
+and MTA-STS (through an smtp_tls_policy_maps plug-in). </p>
<p> The Postfix smtp(8) client process implements the SMTP client
engine. With "smtp_tls_connection_reuse = no", the smtp(8) client
be required if you build Postfix from a vendor-specific source
package. </p>
-<p> The Postfix TLSRPT client builds on a TLSRPT client library
-whose source code can be obtained from: </p>
+<p> The Postfix TLSRPT client builds on a TLSRPT library which may
+be available as a built package (rpm, deb, etc.), or which you can
+build from source code from: </p>
<blockquote>
- <p> https://github.com/sys4/tlsrpt </p>
+<p> https://github.com/sys4/libtlsrpt </p>
</blockquote>
<p> The library is typically installed as a header file in
<p> In order to build Postfix with TLSRPT support, you will need
to add compiler options <tt>-DUSE_TLSRPT</tt> (to build with TLSRPT
-support), and <tt>-I</tt> (with the directory containing the tlsrpt.h
+support) and <tt>-I</tt> (with the directory containing the tlsrpt.h
header file), and you will need to add linker options to link with
the TLSRPT client library, for example: </p>
<pre>
make -f Makefile.init makefiles \
"CCARGS=-DUSE_TLSRPT -I/usr/local/include" \
- "AUXLIBS=-L/usr/local/lib -ltlsrpt"
+ "AUXLIBS=-L/usr/local/lib -Wl,-rpath,/usr/local/lib -ltlsrpt"
</pre>
</blockquote>
+<p> (On Solaris systems you may need to use "<tt>-Wl,-R</tt>" instead
+of "<tt>-Wl,-rpath</tt>".) </p>
+
<p> Then, just run 'make'. </p>
<blockquote>
<p> Note: if your build command line already has CCARGS or AUXLIBS
settings, then simply append the above settings to the existing CCARGS
-or AUXLIBS values. </p>
+or AUXLIBS values: </p>
-<blockquote>
<pre>
make -f Makefile.init makefiles \
- "CCARGS=<i>existing settings...</i> -DUSE_TLSRPT -I/usr/local/include" \
- "AUXLIBS=<i>existing settings...</i> -L/usr/local/lib -ltlsrpt"
+ "CCARGS=... -DUSE_TLSRPT -I/usr/local/include" \
+ "AUXLIBS=... -L/usr/local/lib -Wl,-rpath,/usr/local/lib -ltlsrpt"
</pre>
</blockquote>
-</blockquote>
-
<h2> <a name="using"> Turning on TLSRPT </a> </h2>
<p> After installing Postfix TLSRPT support, you can enable TLSRPT
<blockquote>
<pre>
smtp_tlsrpt_enable = yes
-smtp_tlsrpt_socket_name = /path/to/socket
+smtp_tlsrpt_socket_name = path/to/socket
</pre>
</blockquote>
-<p> The smtp_tlsrpt_socket_name parameter specifies an absolute
-pathname, or a pathname that is relative to $queue_directory. </p>
+<p> The smtp_tlsrpt_socket_name parameter specifies either an
+absolute pathname, or a pathname that is relative to $queue_directory.
+</p>
+
+<p> Notes: </p>
-<blockquote>
+<ul>
-<p> Note: the recommended socket location is still to be determined.
+<li> <p> The recommended socket location is still to be determined.
A good socket location would be under the Postfix queue directory,
for example: "smtp_tlsrpt_socket_name = run/tlsrpt/tlsrpt.sock".
The advantage of using a relative name is that it will work equally
well whether or not Postfix chroot is turned on. </p>
-</blockquote>
+<li> <p> Regardless of whether Postfix chroot is enabled, the TLSRPT
+receiver (<tt>tlsrpt_collectd</tt>) will need to be configured with
+the socket's absolute pathname. </p>
-<p> Do not specify a location under a directory such as <tt>private</tt>
-or <tt>public</tt> that is already used by Postfix programs. Only Postfix
+<li> <p> Do not specify a TLSRPT socket location under a Postfix socket
+directory such as <tt>private</tt> or <tt>public</tt>. Only Postfix
programs should create sockets there. </p>
+</ul>
+
+<p> For details on how to run the TLSRPT collection and reporting
+infrastructure, see the documentation at
+https://github.com/sys4/tlsrpt-reporter.
+
<h2> <a name="logging"> TLSRPT Status logging </a> </h2>
<p> With TLSRPT support turned on, the Postfix TLSRPT client will
<p> <a href="https://datatracker.ietf.org/doc/html/rfc8460#section-3">RFC
8460 Section 3</a> specifies that an MTA must not enforce TLS
-security when sending failure reports via email. However, Postfix
-currently has no way to request that TLS enforcement will be disabled
-when submitting an email message. </p>
+security when sending failure reports via email. </p>
<p> Options:
<ul>
-<li> <p> Specify the "<b>TLS-Required: no</b>" message header,
-defined in RFC 8689, to reduce the TLS security level to "<b>may</b>"
-(that is, do not verify remote SMTP server certificates, and fall
-back to plaintext if TLS is unavailable). <br> <br> This feature
-is available in Postfix 3.10 and later. </p>
+<li> <p> In an email report, specify the "<b>TLS-Required: no</b>"
+message header,
+defined in RFC 8689, to reduce the Postfix SMTP client TLS security
+level to "<b>may</b>" (that is, do not verify remote SMTP server
+certificates, and fall back to plaintext if TLS is unavailable).
+<br> <br> This feature is available in Postfix 3.10 and later. If
+your outbound MTAs run an older version, you can use one of the
+options described below. </p>
<li> <p> Do nothing. When TLS security enforcement is required but
fails, a TLSRPT summary message will be delayed
monitoring service; it takes on average 12 hours before a failure
is reported through TLSRPT. </p>
-<li> <p> Exclude the sender of TLSRPT summaries from TLS security
-enforcement.
+<li> <p> On outbound MTAs that don't support the "<b>TLS-Required:
+no</b>" header feature (such as Postfix 3.9 and earlier), disable
+TLS security enforcement for the sender of TLSRPT summaries.
Implement the configuration below on outbound MTA instances (replace
noreply-smtp-tls-reporting@example.com with your actual report
generator's sender address): </p>
Note the recommended socket location is still to be determined A good socket location would be under the Postfix queue directory for example smtp_tlsrpt_socket_name run tlsrpt tlsrpt sock The advantage of using a relative name is that
with cipher ECDHE RSA AES256 GCM SHA384 256 256 bits
TLSv1 2 with cipher ECDHE RSA AES256 GCM SHA384 256 256 bits
+ The recommended socket location is still to be determined A good socket location would be under the Postfix queue directory for example smtp_tlsrpt_socket_name run tlsrpt tlsrpt sock The advantage of using a relative name is that it
* Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only.
*/
-#define MAIL_RELEASE_DATE "20250127"
+#define MAIL_RELEASE_DATE "20250131"
#define MAIL_VERSION_NUMBER "3.10"
#ifdef SNAPSHOT
const char *rpt_policy_string,
int skip_reused_hs)
{
+ const char myname[] = "trw_create";
TLSRPT_WRAPPER *trw;
+ if (msg_verbose > 1)
+ msg_info("%s(rpt_socket_name=%s, rpt_policy_domain=%s, "
+ "rpt_policy_string=%s, skip_reused_hs=%d)",
+ myname, rpt_socket_name, rpt_policy_domain,
+ rpt_policy_string, skip_reused_hs);
+
/*
* memset() is not portable for pointer etc. types.
*/
void trw_free(TLSRPT_WRAPPER *trw)
{
+ if (msg_verbose > 1)
+ msg_info("trw_free: rpt_socket_name=%s, rpt_policy_domain=%s, ...",
+ trw->rpt_socket_name, trw->rpt_policy_domain);
+
/* Destroy fields set with trw_create(). */
myfree(trw->rpt_socket_name);
myfree(trw->rpt_policy_domain);
const char *tls_policy_domain,
const char *const * mx_host_patterns)
{
+ const char myname[] = "trw_set_tls_policy";
+
+#define STR_OR_NULL(s) ((s) ? (s) : "(Null)")
+#define PSTR_OR_NULL(p) ((p) ? STR_OR_NULL(*p) : "(Null)")
+
+ if (msg_verbose > 1)
+ msg_info("%s(tlsrpt_policy_type_t=%d, tls_policy_strings=%s..., "
+ "tls_policy_domain=%s, mx_host_patterns=%s...)",
+ myname, tls_policy_type,
+ PSTR_OR_NULL(tls_policy_strings),
+ STR_OR_NULL(tls_policy_domain),
+ PSTR_OR_NULL(mx_host_patterns));
+
trw->tls_policy_type = tls_policy_type;
MYFREE_IF_SET_AND_COPY(trw->tls_policy_domain, tls_policy_domain);
if (tls_policy_type == TLSRPT_NO_POLICY_FOUND) {
{
const char myname[] = "trw_set_tcp_connection";
+ if (msg_verbose > 1 && (snd_mta_addr || rcv_mta_name || rcv_mta_addr))
+ msg_info("%s(snd_mta_addr=%s, rcv_mta_name=%s, rcv_mta_addr=%s)",
+ myname, STR_OR_NULL(snd_mta_addr),
+ STR_OR_NULL(rcv_mta_name), STR_OR_NULL(rcv_mta_addr));
+
/*
* Sanity check: usage errors are not a show stopper.
*/
{
const char myname[] = "trw_set_ehlo_resp";
+ if (msg_verbose > 1 && rcv_mta_ehlo)
+ msg_info("%s(rcv_mta_ehlo=%s)", myname, rcv_mta_ehlo);
+
/*
* Sanity check: usage errors are not a show stopper.
*/
struct tlsrpt_connection_t *con;
int res;
+ if (msg_verbose > 1)
+ msg_info("%s(failure_type=%d, additional_info=%s, failure_reason=%s)",
+ myname, failure_type, STR_OR_NULL(additional_info),
+ STR_OR_NULL(failure_reason));
+
/*
* Sanity check: usage errors are not a show stopper.
*/
struct tlsrpt_connection_t *con;
int res;
+ if (msg_verbose > 1)
+ msg_info("trw_report_success");
+
/*
* Sanity check: usage errors are not a show stopper.
*/
projects / thirdparty / postfix.git / commitdiff
