• sendmail snapshot 8.18.0.6

    From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to All on Sun Jan 14 00:48:44 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas S. Kerber@21:1/5 to @esmtp.org on Tue Jan 16 16:27:57 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Wed Jan 17 14:10:57 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Stacey Marshall on Wed Jan 17 11:03:56 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Andreas S. Kerber on Wed Jan 17 13:23:42 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Wed Jan 17 21:20:52 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas S. Kerber@21:1/5 to @esmtp.org on Thu Jan 18 10:14:11 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HQuest@21:1/5 to All on Mon Jan 22 02:58:44 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Mon Jan 22 09:01:21 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas S. Kerber@21:1/5 to Marco Moock on Mon Jan 22 08:36:54 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)