I think qmail is unaffected, but we should really test it.

In particular blast in qmail-smtpd detects stray newlines, and blast in qmail-remote extends \r to \r\n.

The exploit assumes the following

1. The SMTP server supports LF.LF (or LF.CRLF, CRLF.LF) to end the session instead of CRLF.CRLF
2. The SMTP server supports AUTH and PIPELINING.
3. The SMTP server enforces that the address in MAIL FROM matches the email id used for authentication. Basically a SMTP that prevents forging of the MAIL FROM. I tested gmail. It allows any MAIL FROM, but silently changes that to match the authenticated email id and also changes the From entered in the DATA section to match the authenticated user. I'm not aware if there is a standard which says that the AUTH address and MAIL FROM address should be the same.

This exploit doesn't apply to notmail at the moment because

1. notqmail's qmail-smtpd doesn't support LF.LF to end the session. So the smuggling will not work. I have tested this. See the example below
2. notqmail doesn't have AUTH without a patch. Even with the patch, qmail-smtpd allows any MAIL FROM after authentication or once RELAYCLIENT is set. There is no need to smuggle as the fist session itself will allow the mail to be forged.
3. If this were to be implemented in notqmail, one has to have AUTH implemented which doesn't allow MAIL FROM forging.

Example showing notqmail's qmail-smtpd rejects bare LF. Here in the DATA section, the line Test Message is followed by LF.CRLF.

$ cat -v /tmp/mail.txt
mail from:<mbhangui@argos.indimail.org>
rcpt to:<mbhangui@argos.indimail.org>
DATA
From: mbhangui@argos.indimail.org^M
To: testuser01@example.com^M
Subject: Testing BARE LF in DATA^M
Date: Sun, 24 Dec 2023 00:49:21 +0530^M
^M
Test message
.^M
mail from:<admin@argos.indimail.org>
RCPT TO:<mbhangui@argos.indimail.org>
DATA
From: mbhangui@gmail.com
To: testuser02@example.com
Subject: I'm admin
Date: Sun, 24 Dec 2023 00:49:21 +0530

I'm admin now
.
quit

$ ./qmail-smtpd < /tmp/mail.txt
220 argos.indimail.org ESMTP
250 ok
250 ok
354 go ahead
451 See https://cr.yp.to/docs/smtplf.html.

In the outbound direction, reading tests/unittest_qmail-remote.c, we have previously verified that a DATA line ending only in a CR or only in an LF will be adjusted to CRLF. So I think we can conclude that we are also immune to being a vector for smuggling to other SMTP servers.

@DerDakon, with your agreement I'm comfortable closing this, noting in the release notes that we were never vulnerable, and filing a post-1.09 issue suggesting we also be strict about line endings before the DATA phase.