(*) 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.

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

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

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

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.

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

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.

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

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

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

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

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";
}

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