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

[Gregory Shapiro]

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.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[George Mitchell]

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

And speaking of RELENG_13, is this change likely to show up in
FreeBSD 13.3, which is currently going through the beta, then
release candidate, then release cycle? -- George

[Gregory Shapiro]

Post by George Mitchell
And speaking of RELENG_13, is this change likely to show up in
FreeBSD 13.3, which is currently going through the beta, then
release candidate, then release cycle? -- George

Yes, after about a week of baking in stable/13. I've already
communicated with re@ and they are fully supportive.



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ruben van Staveren]

Hi all,

As for the dhparams file, lets use the ffdhe4096 as per RFC7919 one and stop continuing generating these ourselves.
The file can be grabbed from e.g. https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe4096.pem

Not seeing any reason to use the weaker ffdhe3072 / ffdhe2048 for backwards compatibility, but ymmv.

Best Regards,
Ruben

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 ?

[..]

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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208953
As a quick POC, I've provided a simple dhparams_gen.sh script.
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247526&action=edit
I thing something like this can be included in the base and all services from ports and base should be configured to use the same dhparams.pem file easily managed from cron, or manually by one simple command.
The submitted script generates DH params from 1024 to 8192. From what I read on the net, 1024 and 1536 should not be used and from my experience generating anything above 4096 takes too much time (the script runs for hours on a not so modern machine) so I created another version of the dhparams_gen.sh where user can specify what sizes will be generated by defining the range, for example "2048 4096" will generate only 2048 3072 4096 sizes.
It is very simple scripting and as nobody reacted to the PR I didn't post the newer version. I can send it to you I you want.
Kind regards
Miroslav Lachman

[Gregory Shapiro]

Post by Ruben van Staveren
As for the dhparams file, lets use the ffdhe4096 as per RFC7919 one and stop continuing generating these ourselves.
The file can be grabbed from e.g. https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe4096.pem

I seem to recall that sendmail is doing someting along these lines anyhow if the DHParameters file is missing or empty.

Yes, from the documentation:

If the file is not readable or contains unusable data, the default ``i'' is used instead.

``i'' which selects a precomputed, fixed 2048 bit prime.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de