Thanks for the continued sendmail support! One question, I noticed the
new mc file makes the following changes which refers to a file that does
not normally exist on RELENG_13. What is the best way to generate that
file ?
diff -u sendmail.cf build13.sentex.ca.cf
--- sendmail.cf 2024-02-07 18:54:29.649479000 +0000
+++ build13.sentex.ca.cf 2024-02-07 18:55:15.546923000 +0000
@@ -31,6 +31,7 @@
##### $Id: cfhead.m4,v 8.122 2013-11-22 20:51:13 ca Exp $ #####
##### $Id: cf.m4,v 8.33 2013-11-22 20:51:13 ca Exp $ #####
+##### $FreeBSD$ #####
##### $Id: freebsd6.m4,v 1.2 2013-11-22 20:51:15 ca Exp $ #####
@@ -606,7 +607,7 @@
# Directory containing hashes pointing to certificate revocation
status files
#O CRLPath
# DHParameters (only required if DSA/DH is used)
-#O DHParameters
+O DHParameters=/etc/mail/certs/dh.param
# Random data source (required for systems without /dev/urandom under
OpenSSL)
#O RandFile
# fingerprint algorithm (digest) to use for the presented cert
Feb 7 18:56:00 build13 sm-mta[88899]: starting daemon (8.18.1):
SMTP+queueing@00:30:00
Feb 7 18:56:00 build13 sm-mta[88899]: STARTTLS=server: file
/etc/mail/certs/dh.param unsafe: No such file or directory
Feb 7 18:56:00 build13 sm-msp-queue[88902]: starting daemon (8.18.1):
queueing@00:30:00
On 2/7/2024 2:54 AM, Gregory Shapiro wrote:
As noted in UPDATING:
20240207:
sendmail 8.18.1 has been imported and merged. This version enforces
stricter RFC compliance by default, especially with respect to line
endings. This may cause issues with receiving messages from
non-compliant MTAs; please see the first 8.18.1 release note in
contrib/sendmail/RELEASE_NOTES for mitigations.
Here is that release note entry:
8.18.1/8.18.1 2024/01/31
sendmail is now stricter in following the RFCs and rejects
some invalid input with respect to line endings
and pipelining:
- Prevent transaction stuffing by ensuring SMTP clients
wait for the HELO/EHLO and DATA response before sending
further SMTP commands. This can be disabled using
the new srv_features option 'F'. Issue reported by
Yepeng Pan and Christian Rossow from CISPA Helmholtz
Center for Information Security.
- Accept only CRLF . CRLF as end of an SMTP message
as required by the RFCs, which can disabled by the
new srv_features option 'O'.
- Do not accept a CR or LF except in the combination
CRLF (as required by the RFCs). These checks can
be disabled by the new srv_features options
'U' and 'G', respectively. In this case it is
suggested to use 'u2' and 'g2' instead so the server
replaces offending bare CR or bare LF with a space.
It is recommended to only turn these protections off
for trusted networks due to the potential for abuse.
