Path: ...!eternal-september.org!feeder3.eternal-september.org!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.omega.home.tnetconsulting.net!not-for-mail
From: Grant Taylor <gtaylor@tnetconsulting.net>
Newsgroups: comp.mail.sendmail
Subject: Re: Trusted CA config
Date: Fri, 10 Jan 2025 17:45:49 -0600
Organization: TNet Consulting
Message-ID: <vlsbfd$fuf$1@tncsrv09.home.tnetconsulting.net>
References: <87ttcbly3k.fsf@example.com> <vh2uu2$jqr$1@news.misty.com>
 <87h68a526z.fsf@miraculix.mork.no> <87frlsoxci.fsf_-_@miraculix.mork.no>
 <vlrk97$j5j$1@news.misty.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 10 Jan 2025 23:45:49 -0000 (UTC)
Injection-Info: tncsrv09.home.tnetconsulting.net; posting-host="omega.home.tnetconsulting.net:198.18.1.11";
	logging-data="16335"; mail-complaints-to="newsmaster@tnetconsulting.net"
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vlrk97$j5j$1@news.misty.com>
Bytes: 3756
Lines: 68

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