mir/postfix
2
0
Fork 0
mirror of https://github.com/vdukhovni/postfix synced 2025-08-22 01:49:47 +00:00
Code Issues Releases Wiki Activity

postfix-3.10-20250131

Browse Source
This commit is contained in:
Wietse Z Venema 2025-01-31 00:00:00 -05:00 committed by Viktor Dukhovni
parent 01400e7864
commit 592931cd01
8 changed files with 237 additions and 134 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
postfix/HISTORY
View File

@ -28887,4 +28887,14 @@ Apologies for any names omitted.
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.

87
postfix/README_FILES/TLSRPT_README
View File

@ -30,14 +30,12 @@ successful and failed SMTP over TLS connections to domain example.com, and to
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,
@ -45,9 +43,13 @@ When Postfix TLSRPT support is enabled (with "smtp_tlsrpt_enable = yes"):
* 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).
@ -64,33 +66,35 @@ These instructions assume that you build Postfix from source code as described
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"
TTuurrnniinngg oonn TTLLSSRRPPTT
@ -98,20 +102,29 @@ After installing Postfix TLSRPT support, you can enable TLSRPT support in
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.
TTLLSSRRPPTT SSttaattuuss llooggggiinngg
@ -176,16 +189,17 @@ Notes:
DDeelliivveerriinngg TTLLSSRRPPTT ssuummmmaarriieess vviiaa eemmaaiill
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 "TTLLSS--RReeqquuiirreedd:: nnoo" message header, defined in RFC 8689, to
reduce the TLS security level to "mmaayy" (that is, do not verify remote SMTP
server certificates, and fall back to plaintext if TLS is unavailable).
* In an email report, specify the "TTLLSS--RReeqquuiirreedd:: nnoo" message header, defined
in RFC 8689, to reduce the Postfix SMTP client TLS security level to "mmaayy"
(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
@ -193,10 +207,11 @@ Options:
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 "TTLLSS--RReeqquuiirreedd:: nnoo" 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.

114
postfix/html/TLSRPT_README.html
View File

@ -55,32 +55,33 @@ summaries of successful and failed SMTP over TLS connections to domain
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> --&gt; </tt> </td>
<tr> <td align="center" bgcolor="#f0f0ff"> Postfix SMTP and TLS
client engines </td> <td> <tt> &rarr; </tt> </td>
<td align="center" bgcolor="#f0f0ff"> TLSRPT client <br> library
</td> <td> <tt> --&gt; </tt> </td>
<td align="center" bgcolor="#f0f0ff"> <a
href="https://github.com/sys4/libtlsrpt">TLSRPT client library </a>
(linked into Postfix) </td> <td> <tt> &rarr; </tt> </td>
<td align="center" bgcolor="#f0f0ff"> TLSRPT summary <br> generator
</td> <td> <tt> --&gt; </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> &rarr; </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
@ -89,17 +90,20 @@ client engines </td> <td> <tt> --&gt; </tt> </td>
<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
@ -116,11 +120,12 @@ code as described in the <a href="INSTALL.html">INSTALL</a> document. Some modif
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
@ -130,7 +135,7 @@ actual pathnames will depend on OS platform conventions. </p>
<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>
@ -138,28 +143,28 @@ 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
@ -168,27 +173,38 @@ support in <a href="postconf.5.html">main.cf</a> like this: </p>
<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>
<blockquote>
<p> Notes: </p>
<p> Note: the recommended socket location is still to be determined.
<ul>
<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
@ -268,19 +284,20 @@ have the details for why TLS authentication failed. </p>
<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
@ -289,8 +306,9 @@ in the mail queue. Keep in mind that TLSRPT is not a real-time
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>

114
postfix/proto/TLSRPT_README.html
View File

@ -55,32 +55,33 @@ summaries of successful and failed SMTP over TLS connections to domain
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> --&gt; </tt> </td>
<tr> <td align="center" bgcolor="#f0f0ff"> Postfix SMTP and TLS
client engines </td> <td> <tt> &rarr; </tt> </td>
<td align="center" bgcolor="#f0f0ff"> TLSRPT client <br> library
</td> <td> <tt> --&gt; </tt> </td>
<td align="center" bgcolor="#f0f0ff"> <a
href="https://github.com/sys4/libtlsrpt">TLSRPT client library </a>
(linked into Postfix) </td> <td> <tt> &rarr; </tt> </td>
<td align="center" bgcolor="#f0f0ff"> TLSRPT summary <br> generator
</td> <td> <tt> --&gt; </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> &rarr; </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
@ -89,17 +90,20 @@ client engines </td> <td> <tt> --&gt; </tt> </td>
<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
@ -116,11 +120,12 @@ code as described in the INSTALL document. Some modification may
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
@ -130,7 +135,7 @@ actual pathnames will depend on OS platform conventions. </p>
<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>
@ -138,28 +143,28 @@ 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
@ -168,27 +173,38 @@ support in main.cf like this: </p>
<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>
<blockquote>
<p> Notes: </p>
<p> Note: the recommended socket location is still to be determined.
<ul>
<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
@ -268,19 +284,20 @@ have the details for why TLS authentication failed. </p>
<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
@ -289,8 +306,9 @@ in the mail queue. Keep in mind that TLSRPT is not a real-time
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>

1
postfix/proto/stop.double-proto-html
View File

@ -363,3 +363,4 @@ Postfix Postfix legacy TLS Support
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

1
postfix/proto/stop.spell-proto-html
View File

@ -396,3 +396,4 @@ doctype
dtd
marc
LP
collectd

2
postfix/src/global/mail_version.h
View File

@ -20,7 +20,7 @@
* 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

40
postfix/src/tls/tlsrpt_wrapper.c
View File

@ -312,8 +312,15 @@ TLSRPT_WRAPPER *trw_create(const char *rpt_socket_name,
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.
*/
@ -338,6 +345,10 @@ TLSRPT_WRAPPER *trw_create(const char *rpt_socket_name,
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);
@ -362,6 +373,19 @@ void trw_set_tls_policy(TLSRPT_WRAPPER *trw,
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) {
@ -385,6 +409,11 @@ void trw_set_tcp_connection(TLSRPT_WRAPPER *trw,
{
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.
*/
@ -405,6 +434,9 @@ void trw_set_ehlo_resp(TLSRPT_WRAPPER *trw, const char *rcv_mta_ehlo)
{
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.
*/
@ -499,6 +531,11 @@ int trw_report_failure(TLSRPT_WRAPPER *trw,
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.
*/
@ -579,6 +616,9 @@ int trw_report_success(TLSRPT_WRAPPER *trw)
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.
*/