• adding CA certificates (for use by sendmail)

    From Wolfgang Agnes@21:1/5 to All on Tue Nov 12 22:30:07 2024
    XPost: comp.unix.bsd.freebsd.misc

    (*) Follow-up-to

    It's not easy to decide where I should ask a FreeBSD group or sendmail
    one. I'm posting to both, but suggesting a follow-up-to
    comp.mail.sendmail.

    (*) Question

    I'm particularly interested---due to curiosity and my education on the subject---in the following sendmail message in maillog:

    --8<-------------------------------------------------------->8---
    Nov 12 08:27:39 antartida sm-mta[72775]: STARTTLS=client, cert-subject=/CN=mx.google.com, cert-issuer=/C=US/O=Google+20Trust+20Services/CN=WR2, verifymsg=unable to get issuer certificate
    --8<-------------------------------------------------------->8---

    My intuition says the system doesn't have the certificate for the CN mx.google.com. If my intuition is totally wrong, feel free to stop
    reading right here.

    The hostname connecting to my sendmail that generated that line above is

    aspmx.l.google.com

    So I tried (as a guess) to connect to this host on port 25, saying
    STARTTLS and fetching the certificates that came. Because sendmail is
    my primary concern, I installed these certificates in /etc/mail/certs.
    I was afraid that if they were outside of /etc/mail, sendmail would
    refuse to read them. And if my operation were not successful in this conservative approach, then it would be a waste of time to try to move
    these cerficates outside of /etc/mail, so I did not even try that
    because I did not succeed in avoiding the message ``unable to get issuer certificate''.

    I found got three certificates with the -showcerts option by OpenSSL.
    They were GTS_Root_R1_2028.pem---this expires in 2028, but I already had
    one for GTS Root R1 that expires in 2036---, GTS_WR2_RSA.pem and GTS_WR2_EC.pem.

    I obtained them with

    openssl s_client -connect aspmx.l.google.com:25 \
    -starttls smtp \
    -showcerts </dev/null

    I obtained the hash of each certificate with, for example,

    openssl x509 -noout -hash < GTS_Root_R1_2028.pem

    Then I created the symbolic links using these hash as ls shows below.

    # pwd
    /etc/mail/certs

    # ls -l
    total 88
    lrwxr-xr-x 1 root wheel 20 Nov 12 08:26 1001acf7.0 -> GTS_Root_R1_2028.pem lrwxr-xr-x 1 root wheel 10 Nov 1 14:17 382a9cdc.0 -> cacert.pem
    lrwxr-xr-x 1 root wheel 15 Nov 12 08:26 3c8b39ef.0 -> GTS_WR2_RSA.pem lrwxr-xr-x 1 root wheel 19 Nov 12 07:48 462422cf.0 -> ca-lets-encrypt.pem lrwxr-xr-x 1 root wheel 14 Nov 12 08:26 6264a34a.0 -> GTS_WR2_EC.pem -rw-r--r-- 1 root wheel 1566 Nov 10 07:44 ca-lets-encrypt.pem
    -rw-r--r-- 1 root wheel 1318 Nov 1 14:17 cacert.pem
    -rw-r--r-- 1 root wheel 1927 Nov 12 08:25 GTS_Root_R1_2028.pem
    -r--r--r-- 1 root wheel 7395 Nov 12 08:25 GTS_Root_R1.pem
    -rw-r--r-- 1 root wheel 2407 Nov 12 08:25 GTS_WR2_EC.pem
    -rw-r--r-- 1 root wheel 1809 Nov 12 08:25 GTS_WR2_RSA.pem
    -rw-r--r-- 1 root wheel 1350 Nov 1 14:17 host.cert.original
    -rw-r--r-- 1 root wheel 2835 Nov 8 21:15 host.cert.pem
    -rw------- 1 root wheel 1704 Nov 1 14:17 host.key.original
    -rw------- 1 root wheel 241 Nov 8 21:15 host.key.pem

    But that did not change those log messages. I don't know how to debug
    sendmail to the point of seeing which files it is reading. Thanks for
    any advice you might have.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Wolfgang Agnes on Tue Nov 12 22:08:08 2024
    On 11/12/24 19:30, Wolfgang Agnes wrote:
    It's not easy to decide where I should ask a FreeBSD group or
    sendmail one. I'm posting to both, but suggesting a follow-up-to comp.mail.sendmail.

    I get why you chose comp.mail.sendmail. But my take on this is that
    it's more of an OS (lack of certs) issue than it is a Sendmail
    (configuration) issue. But both work for me.

    I'm particularly interested---due to curiosity and my education on
    the subject---in the following sendmail message in maillog:

    --8<-------------------------------------------------------->8---
    Nov 12 08:27:39 antartida sm-mta[72775]: STARTTLS=client, cert-subject=/CN=mx.google.com, cert-issuer=/C=US/O=Google+20Trust+20Services/CN=WR2, verifymsg=unable to get issuer certificate
    --8<-------------------------------------------------------->8---

    My intuition says the system doesn't have the certificate for the CN mx.google.com.

    I interpret it a little bit differently.

    As is true with most Unix errors, the error is staring you in the face.
    But you have to have seen the error before to recognize and understand it:

    unable to get issuer certificate <--

    The issuer is:

    cert-issuer=/C=US/O=Google+20Trust+20Services/CN=WR2 <--

    Or decoded:

    cert-issuer=/C=US/O=Google Trust Services/CN=WR2 <--

    The problem is related to the issuer's (Google Trust Service)
    certificate, not the subject's (mx.google.com) certificate.

    If my intuition is totally wrong, feel free to stop reading right here.

    You're closer than you realize.

    The hostname connecting to my sendmail that generated that line above is

    aspmx.l.google.com

    I think this was from Sendmail /sending/ an email to Google and acting
    as the client to Google's server.

    So I tried (as a guess) to connect to this host on port 25, saying
    STARTTLS and fetching the certificates that came.

    :-)

    Because sendmail is my primary concern, I installed these certificates
    in /etc/mail/certs. I was afraid that if they were outside of
    /etc/mail, sendmail would refuse to read them. And if my operation
    were not successful in this conservative approach, then it would be
    a waste of time to try to move these cerficates outside of /etc/mail,
    so I did not even try that because I did not succeed in avoiding the
    message ``unable to get issuer certificate''.

    I would have to reference documentation to refresh myself on the nuances
    and minutia of /etc/mail/certs to know for sure if that was the proper
    thing to do or not.

    Having fought this type of battle, and won, multiple times, I would have actually opted for the system wide certificate store under /etc/ssl or /etc/tls.

    I found got three certificates with the -showcerts option by OpenSSL.

    Nice. I suspect you're now in the 1% of people that work with TLS on
    the command line. Welcome to the club. And I'm sorry.

    They were GTS_Root_R1_2028.pem---this expires in 2028, but I already had
    one for GTS Root R1 that expires in 2036---, GTS_WR2_RSA.pem and GTS_WR2_EC.pem.

    Those names don't /exactly/ match the issuers that I see when running
    tests on my side, but they are very close.

    I obtained them with

    openssl s_client -connect aspmx.l.google.com:25 \
    -starttls smtp \
    -showcerts </dev/null

    Nice.

    Here's a modified (added STARTTLS bit) version of an excerpt from a
    script I wrote today to check HTTPS chains:

    FQDN=smtp.google.com
    PORT=25

    openssl s_client -showcerts -connect ${FQDN}:${PORT} -STARTTLS smtp 0</dev/null 2>/dev/null | sed -n '/-----BEGIN
    CERTIFICATE-----/,/-----END CERTIFICATE-----/p' > ${FQDN}.pem

    csplit -zf ${FQDN}.pem ${FQDN}.pem '/-----BEGIN CERTIFICATE-----/'
    '{*}' -b ".cert-%0d.pem" > /dev/null

    PARTS=($(ls -1r ${FQDN}.pem.cert-?.pem))

    This leaves us with four files:

    - smtp.google.com.pem - the combined file extracted with s_client
    - smtp.google.com.pem.cert-0.pem - the 1st cert
    - smtp.google.com.pem.cert-1.pem - the 2nd cert
    - smtp.google.com.pem.cert-2.pem - the 3rd cert

    I obtained the hash of each certificate with, for example,

    openssl x509 -noout -hash < GTS_Root_R1_2028.pem

    :-)

    I tend to prefer the `-in ${FILE}` vs redirect approach. But both work.

    Then I created the symbolic links using these hash as ls shows below.

    Regarding your "I already had" comment, it looks like you used ".0" for
    all of your hash files. The .# nomenclature is to allow for different
    files that have the same hash. Unexpected, but not impossible either.

    But that did not change those log messages. I don't know how to
    debug sendmail to the point of seeing which files it is reading.
    Thanks for any advice you might have.

    I think that it's going to depend on how Sendmail is configured. Is it
    using it's own certificate store or the system wide certificate store?

    What is the CACertPath set to in your sendmail.cf file?

    You will need your hash links to be in the directory that Sendmail is
    looking for root certs in.

    When I look at the three smtp.google.com.pem.cert-#.pem files generated
    above, I find that there is a fourth certificate that is needed.

    for ((x=${#PARTS}; x>0; x--)); do
    echo;
    echo ${PARTS[$x]};
    openssl x509 -noout -subject -subject_hash -startdate -enddate
    -issuer -issuer_hash -in ${PARTS[$x]};
    done

    smtp.google.com.pem.cert-0.pem
    subject= /CN=mx.google.com
    6264a34a
    notBefore=Oct 7 08:25:31 2024 GMT
    notAfter=Dec 30 08:25:30 2024 GMT
    issuer= /C=US/O=Google Trust Services/CN=WR2
    3c8b39ef

    smtp.google.com.pem.cert-1.pem
    subject= /C=US/O=Google Trust Services/CN=WR2
    3c8b39ef
    notBefore=Dec 13 09:00:00 2023 GMT
    notAfter=Feb 20 14:00:00 2029 GMT
    issuer= /C=US/O=Google Trust Services LLC/CN=GTS Root R1
    1001acf7

    smtp.google.com.pem.cert-2.pem
    subject= /C=US/O=Google Trust Services LLC/CN=GTS Root R1
    1001acf7
    notBefore=Jun 19 00:00:42 2020 GMT
    notAfter=Jan 28 00:00:42 2028 GMT
    issuer= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
    5ad8a5d6

    The fourth file that's needed is the 5ad8a5d6.0 file (in /etc/ssl/certs
    on my system):

    openssl x509 -noout -subject -subject_hash -startdate -enddate
    -issuer -issuer_hash -in /etc/ssl/certs/5ad8a5d6.0

    subject= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
    5ad8a5d6
    notBefore=Sep 1 12:00:00 1998 GMT
    notAfter=Jan 28 12:00:00 2028 GMT
    issuer= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
    5ad8a5d6

    So, when I ask OpenSSL to verify the chain from smtp.google.com /
    mx.google.com all the way back to the root certificates that my system
    trusts, the chain is valid:

    smtp.google.com.pem.cert-0.pem (6264a34a) issued by 3c8b39ef

    smtp.google.com.pem.cert-1.pem (3c8b39ef) issued by 1001acf7

    smtp.google.com.pem.cert-2.pem (1001acf7) issued by 5ad8a5d6

    And then the trusted root certificate:

    /etc/ssl/certs/5ad8a5d6.0 -> GlobalSign_Root_CA.pem (5ad8a5d6) issued by 5ad8a5d6 (itself)

    openssl verify -verbose -untrusted smtp.google.com.pem.cert-2.pem -untrusted smtp.google.com.pem.cert-1.pem smtp.google.com.pem.cert-0.pem 2>/dev/null
    smtp.google.com.pem.cert-0.pem: OK

    Thus we have a complete chain of trust from the leaf cert used by smtp.google.com 6264a34a, through two intermediary certs (3c8b39ef &
    1001acf7), to a trusted root (5ad8a5d6). Thus a complete chain of trust.

    I think that you're probably on the correct track. I speculate that
    it's a possible mismatch of where Sendmail is looking and where you have
    your files.



    --
    Grant. . . .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John D Groenveld@21:1/5 to gtaylor@tnetconsulting.net on Wed Nov 13 14:39:49 2024
    In article <vh18n8$oeh$1@tncsrv09.home.tnetconsulting.net>,
    Grant Taylor <gtaylor@tnetconsulting.net> wrote:
    I think that you're probably on the correct track. I speculate that
    it's a possible mismatch of where Sendmail is looking and where you have
    your files.

    # uname -sr
    FreeBSD 15.0-CURRENT
    # pkg which /usr/local/share/sendmail/cf/README /usr/local/share/sendmail/cf/README was installed by package sendmail-8.18.1

    # grep CACERT /usr/local/share/sendmail/cf/README
    define(`confCACERT_PATH', `/etc/mail/certs/')
    define(`confCACERT', `/etc/mail/certs/CA.cert.pem')
    confCACERT_PATH CACertPath [undefined] Path to directory with confCACERT CACertFile [undefined] File containing at least

    The OP can use truss(1) to verify sendmail is using the CACERT_PATH
    he thinks it should be using.

    John
    groenveld@acm.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to John D Groenveld on Wed Nov 13 17:53:14 2024
    groenveld@acm.org (John D Groenveld) writes:

    # grep CACERT /usr/local/share/sendmail/cf/README
    define(`confCACERT_PATH', `/etc/mail/certs/')
    define(`confCACERT', `/etc/mail/certs/CA.cert.pem')
    confCACERT_PATH CACertPath [undefined] Path to directory with confCACERT CACertFile [undefined] File containing at least


    Note that CACertPath is for validating servers you connect to (STARTTLS=client), while CACertFile is for validating clients connecting
    to you (STARTTLS=server).

    The latter should only contain CAs under your administrative control if
    you do client certificate based authentication. And that's the only
    point of having anything there.


    Bjørn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to All on Wed Nov 13 14:33:22 2024
    Bjørn Mork wrote:

    Note that CACertPath is for validating servers you connect to (STARTTLS=client), while CACertFile is for validating clients connecting
    to you (STARTTLS=server).

    Please explain why you think this is the case. SSL_CTX_load_verify_locations(*tls_ctx, cacertfile, cacertpath)
    is invoked in inittls() - for server and client side.

    --
    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 =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to All on Wed Nov 13 21:05:56 2024
    Claus Aßmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org>
    writes:
    Bjørn Mork wrote:

    Note that CACertPath is for validating servers you connect to
    (STARTTLS=client), while CACertFile is for validating clients connecting
    to you (STARTTLS=server).

    Please explain why you think this is the case. SSL_CTX_load_verify_locations(*tls_ctx, cacertfile, cacertpath)
    is invoked in inittls() - for server and client side.

    Mainly based on experiments with all sorts of combinations. But looking
    at the code also seems to confirm. The rest of that block is:

    if ((r = SSL_CTX_load_verify_locations(*ctx, cacertfile,
    cacertpath)) == 1)
    {
    # if !TLS_NO_RSA && MTA_RSA_TMP_CB
    if (bitset(TLS_I_RSA_TMP, req))
    SSL_CTX_set_tmp_rsa_callback(*ctx, tmp_rsa_key);
    # endif

    if (srv)
    {
    SSL_CTX_set_client_CA_list(*ctx,
    SSL_load_client_CA_file(cacertfile));
    }
    }


    And the important distinction I wanted to make is theq SSL_CTX_set_client_CA_list() call, which makes cacertfile special wrt
    client certificates.

    Sorry if I've misunderstood something and causing confusion here. But I
    did just have a fight with sendmail over this, trying to make it accept
    only my private CA for client certificates.


    Bjørn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Wolfgang Agnes@21:1/5 to Grant Taylor on Tue Nov 19 10:22:08 2024
    Grant Taylor <gtaylor@tnetconsulting.net> writes:

    On 11/12/24 19:30, Wolfgang Agnes wrote:
    It's not easy to decide where I should ask a FreeBSD group or
    sendmail one. I'm posting to both, but suggesting a follow-up-to
    comp.mail.sendmail.

    I get why you chose comp.mail.sendmail. But my take on this is that
    it's more of an OS (lack of certs) issue than it is a Sendmail (configuration) issue. But both work for me.

    Grant! Good to see you here! Didn't know you were fond of sendmail.
    (You won't know who I am, but we've had USENET-conversations a few
    times.) Writing this quick note just to say thanks and that I'm still
    to read it carefully and reply. I extend my thanks to all others in
    this thread.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to bjorn@mork.no on Thu Jan 9 15:50:21 2025
    Bjørn Mork <bjorn@mork.no> writes:
    Claus Aßmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org>
    writes:
    Bjørn Mork wrote:

    Note that CACertPath is for validating servers you connect to
    (STARTTLS=client), while CACertFile is for validating clients connecting >>> to you (STARTTLS=server).

    Please explain why you think this is the case.
    SSL_CTX_load_verify_locations(*tls_ctx, cacertfile, cacertpath)
    is invoked in inittls() - for server and client side.

    Mainly based on experiments with all sorts of combinations. But looking
    at the code also seems to confirm. The rest of that block is:

    if ((r = SSL_CTX_load_verify_locations(*ctx, cacertfile,
    cacertpath)) == 1)
    {
    # if !TLS_NO_RSA && MTA_RSA_TMP_CB
    if (bitset(TLS_I_RSA_TMP, req))
    SSL_CTX_set_tmp_rsa_callback(*ctx, tmp_rsa_key);
    # endif

    if (srv)
    {
    SSL_CTX_set_client_CA_list(*ctx,
    SSL_load_client_CA_file(cacertfile));
    }
    }

    So I have completely misunderstood this, as Claus correctly pointed
    out. The call to SSL_CTX_load_verify_locations() means that all
    certificates in both CACertPath and CACertFile are equally trusted.

    I was confused by that SSL_CTX_set_client_CA_list() call, which defines
    the list of trusted certificates sent by the server to clients. But this
    list is not enforced. Any certificate signed by a CA in CACertPath is
    also accepted and trusted by the server.

    Can be tested using the openssl s_client application, which happily
    ignores the certificate_authorities hint from the server and sends
    whatever you specify using the -cert, -cert_chain and -key options.

    But how are we supposed to configure a sendmail server then? MTA-STS
    means that the trusted CA list must include every public CA. Using the
    same list to validate client certificates makes them useless. If anyone
    can get a trusted client certificate, then "AUTH EXTERNAL" is pretty
    much an open relay. What am I missing?

    Looking at this, I stumbled across _FFR_CLIENTCA which first appeared
    in 8.16.0.48 (if the Debian git package log is correct). It's
    documented in sendmail/conf.c as

    #if _FFR_CLIENTCA
    /*
    ** Allow to set client specific CA values.
    ** CACertFile: see doc/op.*:
    ** "The DNs of these certificates are sent to the client
    ** during the TLS handshake (as part of the CertificateRequest)
    ** as the list of acceptable CAs.
    ** However, do not list too many root CAs in that file,
    ** otherwise the TLS handshake may fail;"
    ** In TLSv1.3 the certs in CACertFile are also sent by
    ** the client to the server and there is seemingly a
    ** 16KB limit (just in OpenSSL?).
    ** Having a separate CACertFile for the client
    ** helps to avoid this problem.
    */

    "_FFR_CLIENTCA",
    #endif


    This enables two new options, ClientCACertFile and ClientCACertPath,
    which are used instead of CACertFile and CACertPath in client session
    contexts. I.e. the contexts which will validate remote servers, and
    therefore have to include all public CAs if MTA-STS is enabled.

    Server session contexts will continue to use the CACertFile and
    CACertPath for validating clients. So we can now limit those to our
    private CA authorizing mail clients.

    To summarize, this seems to do what I want:

    O ClientCACertFile=/etc/ssl/certs/ca-certificates.crt
    O ClientCACertPath=/etc/ssl/certs
    O CACertPath=/dev/null
    O CACertFile=/etc/mail-client-ca.pem


    where /etc/ssl/certs and /etc/ssl/certs/ca-certificates.crt contains the
    full OS managed list of public CAs, and /etc/mail-client-ca.pem contains
    a single private CA certificate.

    But depending on a build time _FFR which is not enabled in the default
    Debian package worries me. Usually means I'm doing something wrong.
    Comments and suggestions are appreciated



    Bjørn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to All on Fri Jan 10 12:09:59 2025
    Bjørn Mork wrote:

    But how are we supposed to configure a sendmail server then? MTA-STS
    means that the trusted CA list must include every public CA. Using the
    ...
    can get a trusted client certificate, then "AUTH EXTERNAL" is pretty
    much an open relay. What am I missing?

    MTA-STS has probably been "designed" by people who use http(s) for
    everything - without considering the implications. And just like
    SPF it breaks existing e-mail practices....

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Fri Jan 10 17:45:49 2025
    Pre-script: For some reason I don't see the post that Claus quoted, so
    I'm replying to it here.

    Bjørn Mork wrote:
    But how are we supposed to configure a sendmail server then? MTA-STS
    means that the trusted CA list must include every public CA.

    I've been configuring Sendmail to use look in /etc/ssl/certs for trusted
    CAs for years without any problem.

    ... then "AUTH EXTERNAL" is pretty much an open relay.

    I think you're concerned about validated certs being the key to allow relay.

    I have the following in my access(.db) file:

    # Allow REDACTED to relay based on client TLS certificate.
    CERTISSUER:/C=US/O=Let's+20Encrypt/CN=R3 SUBJECT
    CERTSUBJECT:/CN=REDACTED_CN1 RELAY
    CERTSUBJECT:/CN=REDACTED_CN2 RELAY

    As the comment says and the `SUBJECT' value implies, certificates need
    to be from the `CERTISSUER' *AND* have the proper `SUBJECT' listed on in
    it's own `CERTSUBJECT' entry.

    Only my servers are allowed to relay based on valid certificate *AND*
    proper subject.

    What am I missing?

    I suspect that you want to look into `CERTISSUER' of `SUBJECT' combined
    with `CERTSUBJECT' entries to have fine grained control over who's
    allowed to relay based on certificates.

    On 1/10/25 11:09, Claus Aßmann wrote:
    MTA-STS has probably been "designed" by people who use http(s) for
    everything - without considering the implications.

    Where would you have had people publish MTA-STS information? I would
    have preferred DNS, but I don't think that HTTPS is the worst thing in
    the world.

    And just like SPF it breaks existing e-mail practices....

    Please elaborate on what MTA-STS is breaking that it isn't intended to
    break?

    Yes, SPF was intended to break sending email from an unauthorized IP,
    and that includes forwarding. That's by design.

    I've been using and advocating for `-all' SPF records for (nearly) two
    decades at this point. I have no problem forwarding when I use SRS.
    Even Google has changed their tune and was recommending SRS when
    forwarding the last time I looked.

    Yes, I have SRS working with Sendmail just fine. I found an old
    `perlsrs' HACK years ago and have been using it ever sense. I drop the perlsrs.m4 file in the `/usr/share/sendmail/cf/hack' directory and add `HACK(`perlsrs')' to my mc file. It works well enough that I never have
    to think about it. I've been forwarding to Google for years without any problem.

    The only thing you need to do is to make sure that you only forward
    clean email. But I try my best to reject any dirty email at the gate.



    --
    Grant. . . .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas S. Kerber@21:1/5 to Grant Taylor on Sat Jan 11 17:00:02 2025
    Grant Taylor <gtaylor@tnetconsulting.net> wrote:
    Yes, I have SRS working with Sendmail just fine. I found an old
    `perlsrs' HACK years ago and have been using it ever sense. I drop the perlsrs.m4 file in the `/usr/share/sendmail/cf/hack' directory and add `HACK(`perlsrs')' to my mc file. It works well enough that I never have

    Would you mind sharing this 'perlsrs' file? I can't seem to find it and
    I'd like to take a look.

    Andreas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Andreas S. Kerber on Sat Jan 11 11:36:44 2025
    On 1/11/25 11:00, Andreas S. Kerber wrote:
    Would you mind sharing this 'perlsrs' file? I can't seem to find it
    and I'd like to take a look.

    Not at all.

    It's actually multiple files.

    - perlsrs-old.m4 - the original version I found and started with
    - perlsrs.m4 - a test modification of perlsrs-old.m4 to use socketmap
    - socketmap.m4 - a version of (socketmap) perlsrs.m4 I used for a while
    - envfrom2srs.pl - script to convert from SRS form to raw form
    - srs2envto.pl - script to convert from raw form to SRS form
    - socketmapd*.pl - socketmap of above Perl to avoid startup delay

    I only used the socketmap version on one system for a few years before
    giving up on it b/c I'd forget to start the socketmap daemon when the
    system would reboot (patching / etc.).

    I've never had any noticeable performance problems with the
    perlsrs-old.m4 / envfrom2srs.pl / srs2envto.pl versions and they just
    work without needing to remember start anything.

    N.B. you need to change the $secret and $fwdomain. $secret is data
    meant to prevent others from predicting your SRS values. $fwdomain is
    mean to be the domain that you forward emailas; I use the hosts FQDN.

    I save these files in the /etc/mail/srs directory.

    I create a sym-link to the m4 files from where Sendmail / m4 looks for
    hacks (/usr/share/sendmail-cf/hack on my system).

    Then I include the following at the end of my sendmail.mc file:

    HACK(`perlsrs-old')dnl

    The premise behind the m4 is to check to see if the envelope from is in
    class w, and if not, apply SRS to the envelope.

    It's been a long time since I looked at this and I just confirmed that
    it is still working.



    --8<--perlsrs-old.m4--8<--
    divert(-1)

    # Copyright (c) 2004 by Mark Kramer <admin@asarian-host.net>
    # All rights reserved.
    # Copyright (c) 1988, 1993
    # The Regents of the University of California. All rights reserved.
    #
    # By using this file, you agree to the terms and conditions set
    # forth in the LICENSE file which can be found at the top level of
    # the sendmail distribution.
    #
    #

    divert(0)

    VERSIONID(`$Id: perlsrs.m4,v 1.2 2004/04/01 20:37:09 mkramer Exp $')

    ifdef(`_MAILER_DEFINED_',,`errprint(`*** WARNING: MAILER() should be
    before HACK(perlsrs)')')

    LOCAL_CONFIG

    # Forward SRS program map

    Kenvfrom2srs program /etc/mail/srs/envfrom2srs.pl

    # Reverse SRS program map

    Ksrs2envto program /etc/mail/srs/srs2envto.pl

    # SRS regex map

    Kis_srs regex ^<?SRS[01][=+-].*

    MAILER_DEFINITIONS

    SEnvFromSMTP
    R$*@$=w$* $@ $1@$2$3 Don't SRS
    rewrite local (class w) sending domains.
    R$* $: $(envfrom2srs $1 $) SRS rewrite
    non-local (!class w) sending domains.

    LOCAL_RULESETS

    ###################################################################
    ### Local SRS Macros ### ###################################################################

    SIsSRS
    R$* $: $(is_srs $1 $)
    R$@ $@ YES
    R$* $@ NO

    SReverseSrs
    R$* $: $1 $>IsSRS $1
    R$* NO $@ $1
    R$* YES $@ $(srs2envto $1 $)

    LOCAL_RULE_0

    # Do we need to reverse SRS address?

    R$* $: $>ReverseSrs $1
    8--perlsrs-old.m4-->8--



    --8<--perlsrs.m4--8<--
    divert(-1)

    # Copyright (c) 2004 by Mark Kramer <admin@asarian-host.net>
    # All rights reserved.
    # Copyright (c) 1988, 1993
    # The Regents of the University of California. All rights reserved.
    #
    # By using this file, you agree to the terms and conditions set
    # forth in the LICENSE file which can be found at the top level of
    # the sendmail distribution.
    #
    #

    divert(0)

    VERSIONID(`$Id: 8.13.perlsrs.m4,v 1.0 2004/08/21 13:15:43 mkramer Exp $')

    ifdef(`_MAILER_DEFINED_',,`errprint(`*** WARNING: MAILER() should be
    before HACK(perlsrs)')')

    LOCAL_CONFIG

    # SRS socket maps

    Kreverse_srs socket local:/var/run/socketmapd.sock
    Kmake_srs socket local:/var/run/socketmapd.sock

    # SRS regex map

    Kis_srs regex ^<?SRS[01][=+-].*

    MAILER_DEFINITIONS

    SEnvFromSMTP
    R$* $: $(make_srs $1 $)

    LOCAL_RULESETS

    ###################################################################
    ### Local SRS Macros ### ###################################################################

    SIsSrs
    R$* $: $(is_srs $1 $)
    R$@ $@ YES
    R$* $@ NO

    SReverseSrs
    R$* $: $1 $>IsSrs $1
    R$* NO $@ $1
    R$* YES $@ $(reverse_srs $1 $)

    LOCAL_RULE_0

    # Do we need to reverse SRS address?

    R$* $: $>ReverseSrs $1
    8--perlsrs.m4-->8--



    --8<--socketmap.m4--8<--
    divert(-1)

    # Copyright (c) 2004 by Mark Kramer <admin@asarian-host.net>
    # All rights reserved.
    # Copyright (c) 1988, 1993
    # The Regents of the University of California. All rights reserved.
    #
    # By using this file, you agree to the terms and conditions set
    # forth in the LICENSE file which can be found at the top level of
    # the sendmail distribution.
    #
    #

    divert(0)

    VERSIONID(`$Id: socketmap.m4,v 1.0 2004/11/09 13:15:43 mkramer Exp $')

    ifdef(`_MAILER_DEFINED_',,`errprint(`*** WARNING: MAILER() should be
    before HACK(socketmap)')')

    LOCAL_CONFIG

    # SRS socket maps

    Kreverse_srs socket local:/var/run/socketmapd.sock
    Kmake_srs socket local:/var/run/socketmapd.sock

    # SRS regex map

    Kis_srs regex ^<?SRS[01][-+=].*

    MAILER_DEFINITIONS

    SEnvFromSMTP
    R$*@$=w$* $@ $1@$2$3 Don't SRS rewrite local (class
    w) sending domains.
    R$* $: $(make_srs $1 $) SRS rewrite non-local (!class w) sending domains.

    LOCAL_RULESETS

    ###################################################################
    ### Local SRS Macros ### ###################################################################

    SIsSrs
    R$* $: $(is_srs $1 $)
    R$@ $@ YES
    R$* $@ NO

    SReverseSrs
    R$* $: $1 $>IsSrs $1
    R$* NO $@ $1
    R$* YES $@ $(reverse_srs $1 $)

    LOCAL_RULE_0

    # Do we need to reverse SRS address?

    R$* $: $>ReverseSrs $1
    8--socketmap.m4-->8--



    --8<--envfrom2srs.pl--8<--
    #!/usr/bin/perl
    #
    # Sendmail "program" map script to rewrite envelope-from
    # address to SRS0 address. Called from macro EnvFromSMTP.
    #
    # Code by Mark Kramer <admin@asarian-host.net>
    #
    # Version 0.30
    #
    # Last revision: March 24, 2004
    #
    # Licensed under GPL
    #
    # For detailed installation notes, read:
    #
    # http://asarian-host.net/srs/sendmailsrs.htm
    #
    # See also: http://www.anarres.org/projects/srs/
    # http://spf.pobox.com/
    #
    # This version requires at least Sendmail 8.12.10 + Mail::SRS 0.30

    use Mail::SRS;
    use strict;

    # No funny business in our output, please

    close (STDERR);

    my $old_address = $ARGV[0];
    my $secret = 'REDACTED';
    my ($new_address, $use_address);
    my $fwdomain = 'REDACTED';
    my $srs = new Mail::SRS (Secret => $secret, HashLength => 8,
    AlwaysRewrite => 1);

    ###
    open(my $fh, '>>', '/tmp/mylog.txt');
    print $fh "$old_address\n";
    close $fh;
    ###

    # Our original envelope-from may look funny on entry
    # of this Ruleset:
    #
    # admin<@asarian-host.net.>
    #
    # We need to preprocess it some:

    ($use_address = $old_address) =~ s/[<>]//g;
    $use_address =~ s/\.$//g;

    # Here, at EnvFromSMTP, we do not loop our address through an
    # extra IsSrs macro: we want SRS1 forwarding functionality!
    # (relaying reversed third-party SRS1 addresses is a
    # different story, though; but here we just allow for SRS0
    # addresses to be promoted to SRS1 ones).
    #
    # Ok, first check whether we already have a signed SRS address;
    # if so, just return the old address: we do not want to double-sign
    # by accident! (Non-locally generated SRS0 addresses, by nature
    # of the protocol, will not 'eval'; so, they will simply become
    # SRS1 addresses. Thus, only locally generated SRS0 addresses are
    # exempted from double-signing.)
    #
    # Else, gimme a valid SRS signed address, munge it back the way
    # sendmail wants it at this point; or just return the old address,
    # in case nothing went.

    if (eval {$new_address = $srs -> reverse ($use_address)}) {
    print "$old_address\n";
    } elsif (eval {$new_address = $srs -> forward ($use_address, $fwdomain)}) {
    $new_address .= '.>';
    $new_address =~ s/\@/<@/;
    print "$new_address\n";
    } else {
    print "$old_address\n";
    }

    exit 0;
    8--envfrom2srs.pl-->8--



    --8<--srs2envto.pl--8<--
    #!/usr/bin/perl
    #
    # Sendmail "program" map script to revert SRS0 or SRS1 address
    # back to regular recipient. Called from macro ParseLocal.
    #
    # Code by Mark Kramer <admin@asarian-host.net>
    #
    # Version 0.30
    #
    # Last revision: March 24, 2004
    #
    # Licensed under GPL
    #
    # For detailed installation notes, read:
    #
    # http://asarian-host.net/srs/sendmailsrs.htm
    #
    # See also: http://www.anarres.org/projects/srs/
    # http://spf.pobox.com/
    #
    # This version requires at least Sendmail 8.12.10 + Mail::SRS 0.30

    use Mail::SRS;
    use strict;

    # No funny business in our output, please

    close (STDERR);

    my $old_address = $ARGV[0];
    my $secret = 'REDACTED';
    my $use_address;
    my $srs = new Mail::SRS (Secret => $secret, HashLength => 8,
    AlwaysRewrite => 1);

    # Munge ParseLocal recipient in the same manner as required
    # in EnvFromSMTP.

    ($use_address = $old_address) =~ s/[<>]//g;
    $use_address =~ s/\.$//g;

    # Just try and reverse the address. If we succeed, return this
    # new address; else, return the old address (quoted if it was
    # a piped alias).
    #
    # We do an exhaustive while loop, so that SRS1 address may
    # become SRS0, which, in turn, may become reverted to
    # a local recipient.
    #
    # Mail:SRS, as of 0.30, is now case-insensitive. Added the
    # /i switch to accomodate for the change.

    if ($use_address =~ /^SRS[01][=+-]/i) {
    $use_address = $_ while (eval {$_ = $srs -> reverse ($use_address)});
    $use_address .= '.>';
    $use_address =~ s/\@/<@/;
    print "$use_address\n";
    } elsif ($use_address =~ /^\|/) {
    print "\"$old_address\"\n";
    } else {
    print "$old_address\n";
    }

    exit 0;
    8--srs2envto.pl-->8--



    --8<--socketmapd.0.31.pl--8<--
    #!/usr/bin/perl

    # Sendmail "socket" map script to perform SRS functions.
    #
    # Code by Mark Kramer <admin@asarian-host.net>
    #
    # Version 0.31
    #
    # Last revision: November 2, 2004
    #
    # With thanks to Jim Allen for pointing out a missing
    # "while (!eof($client))" loop, causing BROKEN PIPE errors
    # on concurrent connections.
    #
    # Licensed under GPL
    #
    # For detailed installation notes, read:
    #
    # http://asarian-host.net/srs/sendmailsrs.htm
    #
    # See also: http://www.anarres.org/projects/srs/
    # http://spf.pobox.com/
    #
    # This version requires at least Sendmail 8.13.0 + Mail::SRS 0.30

    use IO::Socket;
    use POSIX qw (:sys_wait_h);
    use Sys::Syslog qw (:DEFAULT setlogsock);
    use Mail::SRS;
    use strict;

    my ($user, $login, $pass, $uid, $gid, $data, $socket_map, $old_address, $new_address, $use_address, $client, $sock);
    my $secret = 'REDACTED';
    my $fwdomain = 'REDACTED';
    my $srs = new Mail::SRS (Secret => $secret, MaxAge => 8, HashLength =>
    8, AlwaysRewrite => 1);

    sub write_syslog {
    setlogsock ('unix');
    openlog ('socketmapd', 'pid,cons', 'lpr') or exit 1;
    syslog ('info', @_);
    closelog ();
    }

    sub log_error_and_exit {
    write_syslog (@_);
    exit 1;
    }

    sub netstringRead {
    my $sock = shift;
    my $saveSeparator = $/;
    $/ = ':';
    my $dataLength = <$sock>;
    write_syslog ("WARNING: cannot read netstring length") unless
    defined ($dataLength);
    chomp ($dataLength);
    my $data;
    if ($sock -> read ($data, $dataLength) == $dataLength) {
    ($sock -> getc () eq ',') or write_syslog ("WARNING: data
    misses closing ,");
    } else {
    write_syslog ("WARNING: received only " . length ($data) . " of $dataLength bytes");
    }
    $/ = $saveSeparator;
    return $data;
    }

    sub netstringWrite {
    my $sock = shift;
    my $data = "OK " . shift;
    write_syslog ("WARNING: $@") if (not eval {print $sock length
    ($data) . ':' . $data . ','});
    }

    sub handleChildConnection {
    my $client = shift;
    while (not eval {eof ($client)}) {
    if (eval {$data = netstringRead ($client)}) {
    if ($data =~ /^(\S+) (\S+)$/) {
    $socket_map = $1;
    $old_address = $2;
    ($use_address = $old_address) =~ s/[<>]//g;
    $use_address =~ s/\.$//g;
    if ($socket_map eq 'reverse_srs') {
    if ($use_address =~ /^SRS[01][-+=]/i) {
    $use_address = $_ while (eval {$_ = $srs ->
    reverse ($use_address)});
    $use_address .= '.>';
    $use_address =~ s/\@/<@/;
    netstringWrite ($client, $use_address);
    } elsif ($use_address =~ /^\|/) {
    netstringWrite ($client, "\"$old_address\"");
    } else {
    netstringWrite ($client, $old_address);
    }
    } elsif ($socket_map eq 'make_srs') {
    if (eval {$new_address = $srs -> reverse
    ($use_address)}) {
    netstringWrite ($client, $old_address);
    } elsif (eval {$new_address = $srs -> forward ($use_address, $fwdomain)}) {
    $new_address .= '.>';
    $new_address =~ s/\@/<@/;
    netstringWrite ($client, $new_address);
    } else {
    netstringWrite ($client, $old_address);
    }
    } else {
    write_syslog ("WARNING: unknown socketmap, '$socket_map'");
    }
    } else {
    write_syslog ("WARNING: incomplete data, '$data'");
    }
    } else {
    write_syslog ("WARNING: unable to read from client");
    }
    }
    }

    if (not $user = lc ($ARGV[0])) {
    print STDERR "Missing user\n";
    print STDERR "Usage: $0 <user to run as>\n";
    exit 1;
    } elsif ($>) {
    print STDERR "You need to start socketmapd as root!\n";
    exit 1;
    } else {
    ($login, $pass, $uid, $gid) = getpwnam ($user);
    if (not defined ($uid)) {
    log_error_and_exit ("$user is not a valid user on this system!");
    } elsif (not $uid) {
    log_error_and_exit ("You cannot run socketmapd as root!");
    }
    }

    open (STDIN, '/dev/null');
    open (STDOUT, '>/dev/null');
    open (STDERR, '>&STDOUT');

    umask (0027);

    unlink ('/var/run/socketmapd.pid');
    unlink ('/var/run/socketmapd.sock');

    if ($_ = fork ()) {
    open (USERLOG, ">".'/var/run/socketmapd.pid') or exit 1;
    flock (USERLOG, 2);
    seek (USERLOG, 0, 0);
    print USERLOG " $_";
    close (USERLOG);
    exit 0;
    }

    POSIX::setsid () || exit 1;

    if (not (eval {$sock = new IO::Socket::UNIX (
    Listen => SOMAXCONN,
    Type => SOCK_STREAM,
    Local => '/var/run/socketmapd.sock')})) {
    log_error_and_exit ("ERROR: Unable to create UNIX domain socket!");
    }

    chown $uid, $gid, '/var/run/socketmapd.sock';

    $0 = 'socketmapd';

    $) = $gid;
    $( = $gid;
    = $uid;
    $< = $uid;

    write_syslog ("Dropped privileges on socketmap daemon");

    while (eval {$client = $sock -> accept ()}) {
    if (fork) {
    eval {$client -> close ()};
    wait;
    } elsif (fork) {
    exit 0;
    } else {
    eval {$sock -> close ()};
    eval {handleChildConnection ($client)};
    eval {$client -> close ()};
    exit 0;
    }
    }

    write_syslog ("Unsuccessful exit from the socketmap daemon: $!");

    eval {$sock -> close ()};

    exit 0;
    8--socketmapd.0.31.pl-->8--



    --
    Grant. . . .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to Grant Taylor on Sun Jan 12 16:25:02 2025
    Grant Taylor <gtaylor@tnetconsulting.net> writes:

    Pre-script: For some reason I don't see the post that Claus quoted,
    so I'm replying to it here.

    Bjørn Mork wrote:
    But how are we supposed to configure a sendmail server then? MTA-STS
    means that the trusted CA list must include every public CA.

    I've been configuring Sendmail to use look in /etc/ssl/certs for
    trusted CAs for years without any problem.

    ... then "AUTH EXTERNAL" is pretty much an open relay.

    I think you're concerned about validated certs being the key to allow relay.

    I have the following in my access(.db) file:

    # Allow REDACTED to relay based on client TLS certificate.
    CERTISSUER:/C=US/O=Let's+20Encrypt/CN=R3 SUBJECT
    CERTSUBJECT:/CN=REDACTED_CN1 RELAY
    CERTSUBJECT:/CN=REDACTED_CN2 RELAY

    As the comment says and the `SUBJECT' value implies, certificates need
    to be from the `CERTISSUER' *AND* have the proper `SUBJECT' listed on
    in it's own `CERTSUBJECT' entry.

    Only my servers are allowed to relay based on valid certificate *AND*
    proper subject.

    Yes, that works fine for relaying on an already authenticated session,
    or a session where authentication is not required. I used to do it like
    that too.

    But allowing relaying is not the same as "AUTH EXTERNAL". The MSA
    config will typically look like:

    DAEMON_OPTIONS(`Family=inet6, Name=MSA, Port=submission, M=Ea')

    Which means that you need to authenticate before any of the access db
    rules are evaluated. And authenticated users are trusted and can relay
    anyway.

    Client certificate authentication is simple to configure. Just add
    EXTERNAL to your confAUTH_MECHANISMS and set TRUST_AUTH_MECH(`EXTERNAL')
    But unfortunately there is no way to further limit the set of trusted
    client CAs when you do this.

    What am I missing?

    I suspect that you want to look into `CERTISSUER' of `SUBJECT'
    combined with `CERTSUBJECT' entries to have fine grained control over
    who's allowed to relay based on certificates.

    Does not replace "AUTH EXTERNAL"

    I'm actually quite happy now with the separate ClientCACertFile and ClientCACertPath. Those were the missing part. Just crossing may fingers
    that _FFR_CLIENTCA and _FFR_TLS_USE_CERTIFICATE_CHAIN_FILE are upgraded
    to default soon (or at least that I can get Debian to build their
    sendmail package with it).

    BTW; how many versions are the _FFR build options supposed to stay before either being deprecated or made default?

    On 1/10/25 11:09, Claus Aßmann wrote:
    MTA-STS has probably been "designed" by people who use http(s) for
    everything - without considering the implications.

    Where would you have had people publish MTA-STS information? I would
    have preferred DNS, but I don't think that HTTPS is the worst thing in
    the world.

    DANE is the DNS based solution and it works quite nicely. We didn't
    need MTA-STS. We needed more push for DNSSEC everywhere.

    There are a few things about MTA-STS which doesn't align very well with traditional email configurations. One thing is the "trust all public
    CAs" requirement, which also implies that you have to use a certificate
    from one of those for your own server. Another annoyance is that you
    must set up a https service with a specific well-known DNS name for each
    email domain you want to host. The protocol trusts DNS anyway, so I see
    no reason the policy URL couldn't be configured in DNS.


    Bjørn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to All on Wed Jan 22 12:22:44 2025
    Bjørn Mork wrote:

    BTW; how many versions are the _FFR build options supposed to stay before either being deprecated or made default?

    There's no rule for it. Some FFRs exist "forever", some are turned
    "on" within one release - usually the developers make a decision
    based on "perceived usefulness".

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