Mailing List Archive

240109 Walter Dnes wrote:
> I'll soon be switching over from cable to fibre. It's the same ISP,
> but I'll be needing to authenticate outbound email on port 587.
> Is anybody else doing this ? If so, what changes does ~/.mutt/muttrc need ?

IIRC we both live in/near Toronto, so no doubt Big Bad Bell is responsible.
I could no longer use my ISP via Bell, as they can't use fibre
(this was recently changed by the Feds, but no doubt only after some delay).
Hence I'm now relying on my landlord's free Wifi
or my new cellphone's Hotspot facility for the I/net
(I fired Bell & now use Koodo, a sub of Telus),
but retain my ISP's mail service ( CAD 3 / mth ),
for which I too need to authenticate myself for access.

My notes tell me (set up Mutt in new machine ANB6) :

'USE="mbox" emerge mutt procmail fetchmail ssmtp'
cp fr ANB5 : /etc/ssmtp/ ~/.fetchmailrc ~/.procmailrc
/etc/group : add '<username>' to 'ssmtp'

and (authenticate for mail access) :

Send mail via Wifi : new procedure, as prev'ly no security needed ;
now CIN has to be told who it's dealing w.
We now need a hostname, so add 'anb6' to /etc/hostname ;
in /etc/dhcpcd.conf , add 'hostname anb6' ;
make sure 'hostname' service is in 'default' runlevel.
Mutt uses its own 'smtp', so we need to add in .muttrc :
'set ssl_starttls=yes
set ssl_force_tls=yes
set smtp_url="smtp://<username>@smtp.ca.inter.net:25"
set smtp_pass="<password>"'
We also need in /etc/hosts : '127.0.0.1 anb6 localhost'

I don't know anything re Port 587 : how do I find out my port number ?

BTW I do recommend ca.inter.net (their name) for I/net + e-mail :
I've used them happily for 15 years ; they are in Waterloo, Ont.

HTH

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatcadotinterdotnet

On Tue, Jan 09, 2024 at 02:54:06PM -0500, Philip Webb wrote
>
> IIRC we both live in/near Toronto, so no doubt Big Bad Bell is
> responsible.

I'm currently on EBOX cable. Bell bought them https://www.newswire.ca/news-releases/bell-acquires-longueuil-based-internet-provider-ebox-819104090.html
but EBOX still operates as a separate brand. After the purchase Bell is
now a TPIA customer of Rogers (giggle) for EBOX cable customers. Bell
obviously doesn't like this and wants to route my traffic over their own
fibre so they don't have to pay Rogers.

> My notes tell me (set up Mutt in new machine ANB6) :
>
> /etc/group : add '<username>' to 'ssmtp'

Wierd; I've been running for years without that. mutt passes email
to ssmtp which passes it on to the EBOX smtp server.

> and (authenticate for mail access) :
>
> Send mail via Wifi : new procedure, as prev'ly no security needed ;
> now CIN has to be told who it's dealing w.

I think something similar is happening to me. Because their networks
are probably still separate, the EBOX smtp server sees Bell fibre
traffic as coming from "an external network", requiring authentication.

> 'set ssl_starttls=yes
> set ssl_force_tls=yes
> set smtp_url="smtp://<username>@smtp.ca.inter.net:25"
> set smtp_pass="<password>"'
>
> I don't know anything re Port 587 : how do I find out my port number ?

Thanks for the settings. From my Google searches, the ":25" in
"smtp_url" indicates port 25. User posts on the EBOX DSLReports forum
all seem to talk about port 587 for fibre customers. Wikipedia
https://en.wikipedia.org/wiki/SMTP_Authentication says "generally on
port 587", so apparently it can work on other ports. In your case, "if
it ain't broke, don't fix it".

> BTW I do recommend ca.inter.net (their name) for I/net + e-mail :
> I've used them happily for 15 years ; they are in Waterloo, Ont.

As an incentive to go fibre, EBOX/Bell is offering me somewhat faster
fibre service for the same price I'm paying now. My invoice for Dec
2023 is the same price as for Nov 2020, unlike Bell who constantly raise
prices. I'd like to hang around if EBOX keeps their rates static. I
checked the ca.inter.net website. There are asterisks beside the
monthly price... which goes up $10 after the first 12 months.

--
Roses are red
Roses are blue
Depending on their velocity
Relative to you

I haven't been switched over to fibre yet due to config problems, but
I'm trying to test port 587 using your settings. I recompiled mutt
adding USE="debug gnutls". With "mutt -d 2" I get the a lot of debug
output, including the following. To further complicate things, when I
switch back to the old muttrc, I get something about "no From:" I had
to rebuild without gnutls to get it working again. What do the last 2
lines imply?

[2024-01-18 11:36:00] Sending message...
[2024-01-18 11:36:00] Looking up smtp.ebox.ca...
[2024-01-18 11:36:00] Connecting to smtp.ebox.ca...
[2024-01-18 11:36:00] Connected to smtp.ebox.ca:587 on fd=4
[2024-01-18 11:36:00] 4< 220 smtp.ebox.ca ESMTP Postfix (Debian/GNU)
[2024-01-18 11:36:00] 4> EHLO waltdnes.org
[2024-01-18 11:36:00] 4< 250-smtp.ebox.ca
[2024-01-18 11:36:00] 4< 250-PIPELINING
[2024-01-18 11:36:00] 4< 250-SIZE 20000000
[2024-01-18 11:36:00] 4< 250-VRFY
[2024-01-18 11:36:00] 4< 250-ETRN
[2024-01-18 11:36:00] 4< 250-STARTTLS
[2024-01-18 11:36:00] 4< 250-ENHANCEDSTATUSCODES
[2024-01-18 11:36:00] 4< 250-8BITMIME
[2024-01-18 11:36:00] 4< 250 DSN
[2024-01-18 11:36:00] 4> STARTTLS
[2024-01-18 11:36:00] 4< 220 2.0.0 Ready to start TLS
[2024-01-18 11:36:00] gnutls_handshake: A packet with illegal or unsupported version was received.
[2024-01-18 11:36:02] Could not negotiate TLS connection

--
Roses are red
Roses are blue
Depending on their velocity
Relative to you

On Thursday, 18 January 2024 17:02:44 GMT Walter Dnes wrote:
> I haven't been switched over to fibre yet due to config problems, but
> I'm trying to test port 587 using your settings. I recompiled mutt
> adding USE="debug gnutls". With "mutt -d 2" I get the a lot of debug
> output, including the following. To further complicate things, when I
> switch back to the old muttrc, I get something about "no From:" I had
> to rebuild without gnutls to get it working again. What do the last 2
> lines imply?
>
> [2024-01-18 11:36:00] Sending message...
> [2024-01-18 11:36:00] Looking up smtp.ebox.ca...
> [2024-01-18 11:36:00] Connecting to smtp.ebox.ca...
> [2024-01-18 11:36:00] Connected to smtp.ebox.ca:587 on fd=4
> [2024-01-18 11:36:00] 4< 220 smtp.ebox.ca ESMTP Postfix (Debian/GNU)
> [2024-01-18 11:36:00] 4> EHLO waltdnes.org
> [2024-01-18 11:36:00] 4< 250-smtp.ebox.ca
> [2024-01-18 11:36:00] 4< 250-PIPELINING
> [2024-01-18 11:36:00] 4< 250-SIZE 20000000
> [2024-01-18 11:36:00] 4< 250-VRFY
> [2024-01-18 11:36:00] 4< 250-ETRN
> [2024-01-18 11:36:00] 4< 250-STARTTLS
> [2024-01-18 11:36:00] 4< 250-ENHANCEDSTATUSCODES
> [2024-01-18 11:36:00] 4< 250-8BITMIME
> [2024-01-18 11:36:00] 4< 250 DSN
> [2024-01-18 11:36:00] 4> STARTTLS
> [2024-01-18 11:36:00] 4< 220 2.0.0 Ready to start TLS
> [2024-01-18 11:36:00] gnutls_handshake: A packet with illegal or unsupported
> version was received.
> [2024-01-18 11:36:02] Could not negotiate TLS connection

The "no From:" complaint could be fixed by specifying in your muttrc:

set from = "waltdnes@waltdnes.org"

The gnutls error is more cryptic. You'll have to check what certificate is
sent by the server to deduce what causes the gnutls message. You can try
connecting to the server with the openssl s_client:

openssl s_client -connect smtp.ebox.ca\:587 -starttls smtp -showcerts

or with gnutls-cli:

gnutls-cli --starttls-proto smtp smtp.ebox.ca -p 587

then try to negotiate a connection:

ehlo there
...
Ctrl+D

Gnutls should run starttls and when you enter "Ctrl+D" it will print out what
in particular it has a problem with.

The openssl attempt will show the certificates and you can check the whole
chain, in case you missing a certificate. As long as the CA certificate is in
your /etc/ssl/certs/ there shouldn't be a problem.

Alternatively, add the server certificate(s) in '~/.mutt/certificates' and
specify this path by setting 'set certificate_file' in your muttrc. The first
time you try to connect to your server mutt should warn you if there is a
mismatch between the server's certificate and your SMTP server domain CN
field, or anything else. It will ask you to accept it and allow you to
proceed with the connection.

On Thu, Jan 18, 2024 at 06:42:48PM +0000, Michael wrote

> openssl s_client -connect smtp.ebox.ca\:587 -starttls smtp -showcerts

openssl s_client -connect smtp.ebox.ca\:587 -starttls smtp -showcerts > x.txt

For output to x.txt, see file x.txt in attachment logs.tgz

Output to the terminal (stderr ???) is...
========================================================================
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
verify return:1
depth=0 CN = *.ebox.ca
verify return:1
40F73DC2087F0000:error:0A00014D:SSL routines:tls_process_key_exchange:legacy sigalg disallowed or unsupported:../openssl-3.0.12/ssl/statem/statem_clnt.c:2254:
========================================================================

That last line about "legacy sigalg disallowed or unsupported:" looks
rather ominous.

> or with gnutls-cli:
>
> gnutls-cli --starttls-proto smtp smtp.ebox.ca -p 587
>
> then try to negotiate a connection:
>
> ehlo there
> ...
> Ctrl+D
>
> Gnutls should run starttls and when you enter "Ctrl+D" it will print out what

See file y.txt in logs.tgz

My fibre upgrade is delayed, so I'm testing an unneceassary handoff to
port 587 on cable when an "insecure" handoff to port 25 will do. I just
asked the ISP's direct support to confirm that I'm using the correct
credentials. And one last try at "mutt -d 4". Here's a snippet...

========================================================================
[2024-01-20 23:08:56] mwoh: buf[Subject: Test message 1] is short enough
[2024-01-20 23:08:56] Looking up smtp.ebox.ca...
[2024-01-20 23:08:56] Connecting to smtp.ebox.ca...
[2024-01-20 23:08:56] Connected to smtp.ebox.ca:587 on fd=4
[2024-01-20 23:08:56] 4< 220 smtp.ebox.ca ESMTP Postfix (Debian/GNU)
[2024-01-20 23:08:56] 4> EHLO waltdnes.org
[2024-01-20 23:08:56] 4< 250-smtp.ebox.ca
[2024-01-20 23:08:56] 4< 250-PIPELINING
[2024-01-20 23:08:56] 4< 250-SIZE 20000000
[2024-01-20 23:08:56] 4< 250-VRFY
[2024-01-20 23:08:56] 4< 250-ETRN
[2024-01-20 23:08:56] 4< 250-STARTTLS
[2024-01-20 23:08:56] 4< 250-ENHANCEDSTATUSCODES
[2024-01-20 23:08:56] 4< 250-8BITMIME
[2024-01-20 23:08:56] 4< 250 DSN
[2024-01-20 23:08:56] 4> STARTTLS
[2024-01-20 23:08:56] 4< 220 2.0.0 Ready to start TLS
[2024-01-20 23:08:56] gnutls_handshake: A packet with illegal or unsupported version was received.
[2024-01-20 23:08:58] Could not negotiate TLS connection
========================================================================

"illegal or unsupported version" ominous again.

--
Roses are red
Roses are blue
Depending on their velocity
Relative to you

Hi Walter,

On Sunday, 21 January 2024 04:23:34 GMT Walter Dnes wrote:
> On Thu, Jan 18, 2024 at 06:42:48PM +0000, Michael wrote
>
> > openssl s_client -connect smtp.ebox.ca\:587 -starttls smtp -showcerts
>
> openssl s_client -connect smtp.ebox.ca\:587 -starttls smtp -showcerts >
> x.txt
>
> For output to x.txt, see file x.txt in attachment logs.tgz
>
> Output to the terminal (stderr ???) is...
> ========================================================================
> depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN =
> Go Daddy Root Certificate Authority - G2 verify return:1
> depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU =
> http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate
> Authority - G2 verify return:1
> depth=0 CN = *.ebox.ca
> verify return:1
> 40F73DC2087F0000:error:0A00014D:SSL routines:tls_process_key_exchange:legacy
> sigalg disallowed or
> unsupported:../openssl-3.0.12/ssl/statem/statem_clnt.c:2254:
> ========================================================================
>
> That last line about "legacy sigalg disallowed or unsupported:" looks
> rather ominous.

I think you have found the cause of the problem. The signature algorithm SHA1
has been deprecated[1], because SHA1 has known weaknesses to some collision
and pre-image attacks. Theoretically some evil actor could concoct a rogue
certificate which will produce the same SHA1 digest as the Root CA your smtp
server is using. Practically, this is of little concern for a Root CA, IF
your OS trusts directly the Root CA certificate by having it stored in /etc/
ssl/certs/, or in your user's local store for mutt trusted certificates. Both
openssl and gnutls report a successful verification of the certificate chain.


> > or with gnutls-cli:
> >
> > gnutls-cli --starttls-proto smtp smtp.ebox.ca -p 587
> >
> > then try to negotiate a connection:
> >
> > ehlo there
> > ...
> > Ctrl+D
> >
> > Gnutls should run starttls and when you enter "Ctrl+D" it will print out
> > what
> See file y.txt in logs.tgz

Same warning shown in y.txt:

"... RSA key 2048 bits, signed using RSA-SHA1 (broken!)"


> My fibre upgrade is delayed, so I'm testing an unneceassary handoff to
> port 587 on cable when an "insecure" handoff to port 25 will do.

Sending user authentication credentials in the clear is not advisable for the
security conscious.


> I just
> asked the ISP's direct support to confirm that I'm using the correct
> credentials. And one last try at "mutt -d 4". Here's a snippet...
>
> ========================================================================
> [2024-01-20 23:08:56] mwoh: buf[Subject: Test message 1] is short enough
> [2024-01-20 23:08:56] Looking up smtp.ebox.ca...
> [2024-01-20 23:08:56] Connecting to smtp.ebox.ca...
> [2024-01-20 23:08:56] Connected to smtp.ebox.ca:587 on fd=4
> [2024-01-20 23:08:56] 4< 220 smtp.ebox.ca ESMTP Postfix (Debian/GNU)
> [2024-01-20 23:08:56] 4> EHLO waltdnes.org
> [2024-01-20 23:08:56] 4< 250-smtp.ebox.ca
> [2024-01-20 23:08:56] 4< 250-PIPELINING
> [2024-01-20 23:08:56] 4< 250-SIZE 20000000
> [2024-01-20 23:08:56] 4< 250-VRFY
> [2024-01-20 23:08:56] 4< 250-ETRN
> [2024-01-20 23:08:56] 4< 250-STARTTLS
> [2024-01-20 23:08:56] 4< 250-ENHANCEDSTATUSCODES
> [2024-01-20 23:08:56] 4< 250-8BITMIME
> [2024-01-20 23:08:56] 4< 250 DSN
> [2024-01-20 23:08:56] 4> STARTTLS
> [2024-01-20 23:08:56] 4< 220 2.0.0 Ready to start TLS
> [2024-01-20 23:08:56] gnutls_handshake: A packet with illegal or unsupported
> version was received. [2024-01-20 23:08:58] Could not negotiate TLS
> connection
> ========================================================================
>
> "illegal or unsupported version" ominous again.

TLS 1.0 was deprecated in 2021 and there have been up to date Root
certificates issued by this CA using SHA256[2]. Perhaps the server sysadmins
have not yet updated their smtp server's Root CA?

Anyway, to take you forward you can:

1. Keyword the latest gnutls package in case the gnutls verification criteria
have been loosened.

2. Copy the Root CA into the users ~/ and point muttrc to it:

set certificate_file = "~/.mutt/certificates"

3. If everything else fails, having verified yourself the server's Root CA and
child certificates are all legit you can set:

unset ssl_verify_host

Obviously this would not be satisfactory from a security perspective.

[1] https://datatracker.ietf.org/doc/html/rfc8996
[2] https://certs.godaddy.com/repository

On Sun, Jan 21, 2024 at 12:05:45PM +0000, Michael wrote
>
> Anyway, to take you forward you can:
>
> 1. Keyword the latest gnutls package in case the gnutls verification criteria
> have been loosened.
>
> 2. Copy the Root CA into the users ~/ and point muttrc to it:
>
> set certificate_file = "~/.mutt/certificates"
>
> 3. If everything else fails, having verified yourself the server's
> Root CA and child certificates are all legit you can set:
>
> unset ssl_verify_host
>
> Obviously this would not be satisfactory from a security perspective.

Nothing above works, and I wonder if it's something at my end. I keep
getting the same message...

> gnutls_handshake: A packet with illegal or unsupported version was received.

The current net-libs/gnutls-3.8.0 ebuild (and 3.8.1 and 3.8.2) has
sslv2 and sslv3 enabled in IUSE ...but... "emerge -pv gnutls" shows
them hard-masked. Is my system forcing sslv1 and the server rejecting me???

[ebuild R ] net-libs/gnutls-3.8.0:0/30.30::gentoo USE="cxx idn nls openssl seccomp tls-heartbeat tools zlib -brotli -dane -doc -examples -pkcs11 (-sslv2) (-sslv3) -static-libs -test (-test-full) -verify-sig -zstd" 0 KiB

Do you get the same? Do I have to set something in...

make menuconfig
-*- Cryptographic API --->

"emerge -pv mutt"

[ebuild R ] mail-client/mutt-2.2.12::gentoo USE="debug gnutls gpgme hcache imap lmdb mbox nls pop sasl smtp ssl -autocrypt -berkdb -doc -gdbm -gsasl -idn -kerberos -pgp-classic (-prefix) -qdbm (-selinux) -slang -smime-classic -tokyocabinet -vanilla" 0 KiB

I copied certificates from x.txt to .mutt/certificates (see
attachment). Is this correct? And how do I securely pass credentials?

--
Roses are red
Roses are blue
Depending on their velocity
Relative to you

On 1/21/24 11:09, Walter Dnes wrote:
> On Sun, Jan 21, 2024 at 12:05:45PM +0000, Michael wrote
>> Anyway, to take you forward you can:
>>
>> 1. Keyword the latest gnutls package in case the gnutls verification criteria
>> have been loosened.
>>
>> 2. Copy the Root CA into the users ~/ and point muttrc to it:
>>
>> set certificate_file = "~/.mutt/certificates"
>>
>> 3. If everything else fails, having verified yourself the server's
>> Root CA and child certificates are all legit you can set:
>>
>> unset ssl_verify_host
>>
>> Obviously this would not be satisfactory from a security perspective.
> Nothing above works, and I wonder if it's something at my end. I keep
> getting the same message...
>
>> gnutls_handshake: A packet with illegal or unsupported version was received.
> The current net-libs/gnutls-3.8.0 ebuild (and 3.8.1 and 3.8.2) has
> sslv2 and sslv3 enabled in IUSE ...but... "emerge -pv gnutls" shows
> them hard-masked. Is my system forcing sslv1 and the server rejecting me???
>
> [ebuild R ] net-libs/gnutls-3.8.0:0/30.30::gentoo USE="cxx idn nls openssl seccomp tls-heartbeat tools zlib -brotli -dane -doc -examples -pkcs11 (-sslv2) (-sslv3) -static-libs -test (-test-full) -verify-sig -zstd" 0 KiB
I'm no expert, but I think you are mixing versions of SSL and versions
of TLS.  It seems both sslv2 and sslv3 have been deprecated, and my weak
memory says they were replaced by TLS.  Now it looks like you are having
problems trying to use an older TLS which has been replaced by a newer
TLS, although there are no direct use flags for that.
>
> Do you get the same? Do I have to set something in...
>
> make menuconfig
> -*- Cryptographic API --->
>
> "emerge -pv mutt"
>
> [ebuild R ] mail-client/mutt-2.2.12::gentoo USE="debug gnutls gpgme hcache imap lmdb mbox nls pop sasl smtp ssl -autocrypt -berkdb -doc -gdbm -gsasl -idn -kerberos -pgp-classic (-prefix) -qdbm (-selinux) -slang -smime-classic -tokyocabinet -vanilla" 0 KiB
>
> I copied certificates from x.txt to .mutt/certificates (see
> attachment). Is this correct? And how do I securely pass credentials?
>

On Sunday, 21 January 2024 16:09:47 GMT Walter Dnes wrote:
> On Sun, Jan 21, 2024 at 12:05:45PM +0000, Michael wrote
>
> > Anyway, to take you forward you can:
[snip ...]

> Nothing above works, and I wonder if it's something at my end. I keep
> getting the same message...
>
> > gnutls_handshake: A packet with illegal or unsupported version was
> > received.
> The current net-libs/gnutls-3.8.0 ebuild (and 3.8.1 and 3.8.2) has
> sslv2 and sslv3 enabled in IUSE ...but... "emerge -pv gnutls" shows
> them hard-masked. Is my system forcing sslv1 and the server rejecting me???
>
> [ebuild R ] net-libs/gnutls-3.8.0:0/30.30::gentoo USE="cxx idn nls
> openssl seccomp tls-heartbeat tools zlib -brotli -dane -doc -examples
> -pkcs11 (-sslv2) (-sslv3) -static-libs -test (-test-full) -verify-sig
> -zstd" 0 KiB
>
> Do you get the same? Do I have to set something in...
>
> make menuconfig
> -*- Cryptographic API --->
>
> "emerge -pv mutt"
>
> [ebuild R ] mail-client/mutt-2.2.12::gentoo USE="debug gnutls gpgme
> hcache imap lmdb mbox nls pop sasl smtp ssl -autocrypt -berkdb -doc -gdbm
> -gsasl -idn -kerberos -pgp-classic (-prefix) -qdbm (-selinux) -slang
> -smime-classic -tokyocabinet -vanilla" 0 KiB
>
> I copied certificates from x.txt to .mutt/certificates (see
> attachment). Is this correct? And how do I securely pass credentials?

Starting from the end; to securely pass credentials you need an encrypted
connection to the server. For SMTP server authentication this normally takes
place using STARTTLS on port 587, or explicit TLS typically on port 465 or
port 25 depending on your mail provider.

Your locally stored certificate chain should be in multiple .pem files, one
for each certificate. Normally only the Root CA is needed since this was used
to sign all its children certificates in the chain. In the first instance
just store in your ~/.mutt/certificates/ directory the Root CA certificate, to
see if mutt accepts it without gnutls complaining. In your attachment you
have 4 certificates:

1. The certificate used by the SMTP server (a wildcard ebox.ca domain
certificate):

Subject: CN = *.ebox.ca

which is issued by "CN = Go Daddy Secure Certificate Authority - G2".

2. The "Go Daddy Secure Certificate Authority - G2" was in turn issued by "CN
= Go Daddy Root Certificate Authority - G2".

3. The "CN = Go Daddy Root Certificate Authority - G2" was issued by "OU = Go
Daddy Class 2 Certification Authority".

4. Finally, the last certificate "OU = Go Daddy Class 2 Certification
Authority" is the self-signed Root CA. This is the certificate you could copy
into your ~/.mutt/certificates/.

A copy of this certificate should be available in your /etc/ssl/certs/, so you
could copy it and also hash it:

cp /etc/ssl/certs/Go_Daddy_Class_2_CA.pem ~/.mutt/certificates/
cd ~/.mutt/certificates/
ln -s Go_Daddy_Class_2_CA.pem `openssl x509 -hash -noout -in
Go_Daddy_Class_2_CA.pem`.0

Please note the backticks in the above.

If this still won't work, have you considered ditching gnutls on mutt and
trying with vanilla openssl?

$ emerge -pv mutt

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 23.29 s (backtrack: 0/20).

[ebuild N ] mail-client/mutt-2.2.12::gentoo USE="gdbm hcache imap lmdb
nls sasl smtp ssl -autocrypt -berkdb -debug -doc -gnutls -gpgme -gsasl -idn -
kerberos -mbox -pgp-classic -pop (-prefix) -qdbm (-selinux) -slang -smime-
classic -tokyocabinet -vanilla" 5432 KiB

$ emerge -pv gnutls

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 1.45 s (backtrack: 0/20).

[ebuild R ] net-libs/gnutls-3.8.0:0/30.30::gentoo USE="cxx idn nls
openssl seccomp tls-heartbeat zlib -brotli -dane -doc -examples -pkcs11 (-
sslv2) (-sslv3) -static-libs -test (-test-full) -tools -verify-sig -zstd"
ABI_X86="(64) -32 (-x32)" 0 KiB

It may be the openssl is more accommodating for Root CAs using SHA1 and will
allow the connection to complete.

On Tue, Jan 09, 2024 at 02:01:34PM -0500, Walter Dnes wrote
> I'll soon be switching over from cable to fibre. It's the same ISP,
> but I'll be needing to authenticate outbound email on port 587 (long
> story).

Let's start this over again, because I was barking up the wrong
tree. Rather than ASS-uming stuff, I finally asked in my ISP's support
forum and they said...

> Regarding the SMTP server, the port 587 works on any type of
> technology we are offering. It has to be set with SSL, without
> any authentication.

It looks like they know the IP address ranges of their customers.
I'll try again without authentication, and see what happens and get back
with my results. "emerge -pv gnutls mutt" shows...

[ebuild R ] net-libs/gnutls-3.8.0:0/30.30::gentoo USE="cxx idn nls openssl seccomp tls-heartbeat tools zlib -brotli -dane -doc -examples -pkcs11 (-sslv2) (-sslv3) -static-libs -test (-test-full) -verify-sig -zstd" 0 KiB

[ebuild R ] mail-client/mutt-2.2.12::gentoo USE="debug gnutls gpgme hcache imap lmdb mbox nls pop sasl smtp ssl -autocrypt -berkdb -doc -gdbm -gsasl -idn -kerberos -pgp-classic (-prefix) -qdbm (-selinux) -slang -smime-classic -tokyocabinet -vanilla" 0 KiB

I'm busy tonight, so I'll probably get back tomorrow.

--
Roses are red
Roses are blue
Depending on their velocity
Relative to you