Discussion:
adding CA certificates (for use by sendmail)
Add Reply
Wolfgang Agnes
2024-11-13 01:30:07 UTC
Reply
Permalink
(*) 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.
Grant Taylor
2024-11-13 04:08:08 UTC
Reply
Permalink
Post by Wolfgang Agnes
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.
Post by Wolfgang Agnes
I'm particularly interested---due to curiosity and my education on
--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.
Post by Wolfgang Agnes
If my intuition is totally wrong, feel free to stop reading right here.
You're closer than you realize.
Post by Wolfgang Agnes
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.
Post by Wolfgang Agnes
So I tried (as a guess) to connect to this host on port 25, saying
STARTTLS and fetching the certificates that came.
:-)
Post by Wolfgang Agnes
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.
Post by Wolfgang Agnes
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.
Post by Wolfgang Agnes
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.
Post by Wolfgang Agnes
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
Post by Wolfgang Agnes
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.
Post by Wolfgang Agnes
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.
Post by Wolfgang Agnes
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. . . .
John D Groenveld
2024-11-13 14:39:49 UTC
Reply
Permalink
Post by Grant Taylor
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
***@acm.org
Bjørn Mork
2024-11-13 16:53:14 UTC
Reply
Permalink
Post by John D Groenveld
# 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
Claus Aßmann
2024-11-13 19:33:22 UTC
Reply
Permalink
Post by Bjørn Mork
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.
Bjørn Mork
2024-11-13 20:05:56 UTC
Reply
Permalink
Claus Aßmann
Post by Claus Aßmann
Post by Bjørn Mork
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
Bjørn Mork
2025-01-09 14:50:21 UTC
Reply
Permalink
Post by Bjørn Mork
Claus Aßmann
Post by Claus Aßmann
Post by Bjørn Mork
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
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
Claus Aßmann
2025-01-10 17:09:59 UTC
Reply
Permalink
Post by Bjørn Mork
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
...
Post by Bjørn Mork
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....
Grant Taylor
2025-01-10 23:45:49 UTC
Reply
Permalink
Pre-script: For some reason I don't see the post that Claus quoted, so
I'm replying to it here.
Post by Bjørn Mork
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.
Post by Bjørn Mork
... 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.
Post by Bjørn Mork
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.
Post by Bjørn Mork
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.
Post by Bjørn Mork
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. . . .
Andreas S. Kerber
2025-01-11 17:00:02 UTC
Reply
Permalink
Post by Grant Taylor
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
Grant Taylor
2025-01-11 17:36:44 UTC
Reply
Permalink
Post by Andreas S. Kerber
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 <***@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 <***@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 <***@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 <***@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 <***@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 <***@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. . . .
Bjørn Mork
2025-01-12 15:25:02 UTC
Reply
Permalink
Post by Grant Taylor
Pre-script: For some reason I don't see the post that Claus quoted,
so I'm replying to it here.
Post by Bjørn Mork
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.
Post by Bjørn Mork
... then "AUTH EXTERNAL" is pretty much an open relay.
I think you're concerned about validated certs being the key to allow relay.
# 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.
Post by Grant Taylor
Post by Bjørn Mork
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?
Post by Grant Taylor
Post by Bjørn Mork
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

Wolfgang Agnes
2024-11-19 13:22:08 UTC
Reply
Permalink
Post by Grant Taylor
Post by Wolfgang Agnes
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.
Loading...