Re: sendmail 8.18.1 MFC'ed to stable/13 and stable/14

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.
>