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 Newsgroups: comp.mail.sendmail Subject: Re: Trusted CA config Date: Fri, 10 Jan 2025 17:45:49 -0600 Organization: TNet Consulting Message-ID: References: <87ttcbly3k.fsf@example.com> <87h68a526z.fsf@miraculix.mork.no> <87frlsoxci.fsf_-_@miraculix.mork.no> 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: 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. . . .