sendmail snapshot 8.18.0.6 is available for testing. This version
addresses the so-called SMTP smuggling problem (CVE-2023-51765) by
being more strict (see the release notes and doc/op/op.*).
This is a beta release for 8.18.1, please test and provide feedback.

8.18.1/8.18.1 202X/XX/XX
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 CR LF . CR LF 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
CR LF (as required by the RFCs). These checks can
be disabled by the new srv_features options
'U' and 'G', respectively.
It is recommended to only turn these protections off
for trusted networks due to the potential for abuse.
Full DANE support is available if OpenSSL versions 1.1.1 or 3.x
are used, i.e., TLSA RR 2-x-y and 3-x-y are supported
as required by RFC 7672.
OpenSSL version 3.0.x is supported. Note: OpenSSL 3 loads by
default an openssl.cnf file from a location specified
in the library which may cause unwanted behaviour
in sendmail. Hence sendmail sets the environment
variable OPENSSL_CONF to /etc/mail/sendmail.ossl
to override the default. The file name can be
changed by defining confOPENSSL_CNF in the mc file;
using an empty value prevents setting OPENSSL_CONF.
Note: referring to a file which does not exist does
not cause an an error.
Two new values have been added for {verify}:
"DANE_TEMP": DANE verification failed temporarily.
"DANE_NOTLS": DANE was required but STARTTLS was not
offered by the server.
The default rules return a temporary error for these
cases, so delivery is not attempted.
If the TLS setup code in the client fails and DANE requirements
exist then {verify} will be set to "DANE_TEMP" thus
preventing delivery by default.
DANE related logging has been slightly changed for clarification:
"DANE configured in DNS but no STARTTLS available"
changed to
"DANE configured in DNS but STARTTLS not offered"
When the compile time option USE_EAI is enabled, vacation could
fail to respond when it should (the code change in
8.17.2 was incomplete). Problem reported by Alex
Hautequest.
If SMTPUTF8 BODY=7BIT are used as parameters for the MAIL command
the parsing of UTF8 addresses could fail (USE_EAI).
If a reply to a previous RCPT was received while sending
another RCPT in pipelining mode then parts of the
reply could have been assigned to the wrong RCPT.
New DontBlameSendmail option CertOwner to relax requirement
for certificate public and private key ownership.
Based on suggestion from Marius Strobl of the
FreeBSD project.
clt_features was not checked for connections via Unix domain
sockets.
CONFIG: FEATURE(`enhdnsbl') did not handle multiple replies
from DNS lookups thus potentially causing random
"false negatives".
Note: the fix creates an incompatibility:
the arguments must not have a trailing dot anymore
because the -a. option has been removed (as it only
applies to the entire result, not individual values).
VACATION: Add support for Return-Path header to set sender
to match OpenBSD and NetBSD functionality.
VACATION: Honor RFC3834 and avoid an auto-reply if
'Auto-Submitted: no' is found in the headers to
match OpenBSD and NetBSD functionality.
VACATION: Avoid an auto-reply if a 'List-Id:' is found in
the headers to match OpenBSD functionality.
VACATION: Add support for $SUBJECT in .vacation.msg which
is replaced with the first line of the subject of the
original message to match OpenBSD and NetBSD
functionality.
Portability:
Add support for Darwin 23.
New Files:
cf/feature/fips3.m4
devtools/OS/Darwin.23.x

Available at:
https://ftp.sendmail.org/snapshots/sendmail.8.18.0.6.tar.gz
https://ftp.sendmail.org/snapshots/sendmail.8.18.0.6.tar.gz.sig

SHA256 (sendmail.8.18.0.6.tar.gz) = f919d407fe28cb8f7a61d1f99af9f1918ee5c173ab5f4241002f31c790c71c09
SHA256 (sendmail.8.18.0.6.tar.gz.sig) = d0862ee4588ce04dd844db2c1f8aedccbdd9dde4e3645e15720a331b7c25677e

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Claus Aßmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org> wrote:
> sendmail snapshot 8.18.0.6 is available for testing. This version
> addresses the so-called SMTP smuggling problem (CVE-2023-51765) by
> being more strict (see the release notes and doc/op/op.*).
> This is a beta release for 8.18.1, please test and provide feedback.

Hi Claus,

thanks for the great work!

It's nice to see that srv_features 'o' is now default and I believe
all new options work as they should.

Just a heads up from my personal operational perspective: After trying
hard to live with the new, also per default enabled, "Bare CR/LF" handling,
I finally had to give up and decided to set 'U' and 'G' for all connecting
clients. There's is so much crap out there and manually adding the
offenders to access.db was futile (in my case).

I guess some users of sendmail 8.18.X might find some suprise in regards to
the new "Bare CR/LF" default options.

Just wanted to share that.

Am 16.01.2024 um 16:27:57 Uhr schrieb Andreas S. Kerber:

> I finally had to give up and decided to set 'U' and 'G' for all
> connecting clients. There's is so much crap out there and manually
> adding the offenders to access.db was futile (in my case).

Are those internal or external machines that send bare CR or LF?

Hi Claus,

Built and testing on Oracle Solaris 11.4, no issues to date.

Do you have a release date in mind for 8.18.1, as I presume from the
announcement that you'd prefer that for the official fix.

Regards,
Stacey

Stacey Marshall wrote:

> Built and testing on Oracle Solaris 11.4, no issues to date.

Thanks for the feedback!

> Do you have a release date in mind for 8.18.1, as I presume from the

"When it's ready" (we never publish release dates).

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Andreas S. Kerber wrote:

> I finally had to give up and decided to set 'U' and 'G' for all connecting
> clients. There's is so much crap out there and manually adding the

Can you share the names of (some of) those clients?
Especially those which seem to be "legitimate"?
That would be very interesting!

We had an internal discussion about these features -- and decided
to do "the right thing", i.e., what is required by the RFCs.
But if if breaks "too much" then we might (have to) reconsider.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Am 17.01.2024 um 13:23:42 Uhr schrieb Claus Aßmann:

> We had an internal discussion about these features -- and decided
> to do "the right thing", i.e., what is required by the RFCs.

That is what I think is the best solution.

> But if if breaks "too much" then we might (have to) reconsider.

Users of sendmail have the option to change the behavior and it is
documented in the release notes.

Maybe on upgrades via apt/dnf, an urgent release notes message could be
shown, like Debian already does with apt-listchanges when packages are
changed in a way that may break certain things. The maintainers of those
packages might consider using that way to inform users about that
change.

Operating systems can also ship sendmail.mc files with those
srv_options already enabled if they really think that is needed.

Claus Aßmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org> wrote:
> > I finally had to give up and decided to set 'U' and 'G' for all connecting
> > clients. There's is so much crap out there and manually adding the

> Can you share the names of (some of) those clients?
> Especially those which seem to be "legitimate"?
> That would be very interesting!

Hi,

here's a list of external stuff that arrived during a 12 hour period on our MX.

There we're also some internal/legacy sources and whitelisting seemed doable
for a while, but when MS365 and sendgrid started to appear too I chickend out.
I was just not ready for another round of argument with customers complaining
and it's hard to assess the legitimacy of that stuff. As far I could track, >80%
of it (really) was legitimate and customer would have gone angry sooner or later.

cable-78-34-81-23.nc.de info=Bare linefeed (LF) not allowed
cgn-89-0-5-191.nc.de info=Bare linefeed (LF) not allowed
cp-db.cp-soft.de info=Bare linefeed (LF) not allowed
fmfe04.freemail.hu info=Bare carriage return (CR) not allowed
fmfe05.freemail.hu info=Bare carriage return (CR) not allowed
mail1.mauve.email info=Bare carriage return (CR) not allowed
mail201.ruv.de info=Bare linefeed (LF) not allowed
mail.adenbeck.at info=Bare carriage return (CR) not allowed
mail-am6eur05on20601.outbound.protection.outlook.com info=Bare carriage return (CR) not allowed
mail-am7eur03on20600.outbound.protection.outlook.com info=Bare carriage return (CR) not allowed
mail-db3eur04on0714.outbound.protection.outlook.com info=Bare carriage return (CR) not allowed
mail-db5eur02on20600.outbound.protection.outlook.com info=Bare carriage return (CR) not allowed
mail-db5eur02on20601.outbound.protection.outlook.com info=Bare carriage return (CR) not allowed
mail-db8eur05on20600.outbound.protection.outlook.com info=Bare carriage return (CR) not allowed
mail-db8eur05on20602.outbound.protection.outlook.com info=Bare carriage return (CR) not allowed
mail-db8eur05on2060e.outbound.protection.outlook.com info=Bare carriage return (CR) not allowed
mail-db8eur05on20610.outbound.protection.outlook.com info=Bare carriage return (CR) not allowed
mail-he1eur04on0604.outbound.protection.outlook.com info=Bare carriage return (CR) not allowed
mail-vi1eur02on2061a.outbound.protection.outlook.com info=Bare carriage return (CR) not allowed
mail-vi1eur04on0616.outbound.protection.outlook.com info=Bare carriage return (CR) not allowed
mail-vi1eur05on20600.outbound.protection.outlook.com info=Bare carriage return (CR) not allowed
mx.concloo.net info=Bare carriage return (CR) not allowed
ns.in4vent.sk info=Bare carriage return (CR) not allowed
server2015.systemmarketing.de info=Bare carriage return (CR) not allowed
wfbtwhbs.outbound-mail.sendgrid.net info=Bare carriage return (CR) not allowed

Instead of a binary option, could we add entries into access.db to accept CR or LF only for certain trusted locations? I understand even those trusted locations can be abused, but it is less worrisome for a handful domains to be allowed than every single domain out there.

Am 22.01.2024 um 02:58:44 Uhr schrieb HQuest:

> Instead of a binary option, could we add entries into access.db to
> accept CR or LF only for certain trusted locations?

srv_features can normally be used in access_db, either for all
connections or for IP subnets, single IP addresses or domain names.
Doesn't that work for the new options O, U and G?

Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
> srv_features can normally be used in access_db, either for all
> connections or for IP subnets, single IP addresses or domain names.
> Doesn't that work for the new options O, U and G?

Works fine.