info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?
42 views
Skip to first unread message
Walter Dnes
Jan 9, 2024, 2:10:05 PMJan 9
to
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). Is anybody else doing this? If so, what changes does
~/.mutt/muttrc need? I've "asked Mr. Google" but the hits are ancient,
often referring to dead URLs. I'm sure that mutt's config has changed
over the years.
--
Roses are red
Roses are blue
Depending on their velocity
Relative to you
but I'll be needing to authenticate outbound email on port 587 (long
story). Is anybody else doing this? If so, what changes does
~/.mutt/muttrc need? I've "asked Mr. Google" but the hits are ancient,
often referring to dead URLs. I'm sure that mutt's config has changed
over the years.
--
Roses are red
Roses are blue
Depending on their velocity
Relative to you
Philip Webb
Jan 9, 2024, 3:00:05 PMJan 9
to
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.
> I'll soon be switching over from cable to fibre. It's the same ISP,
> 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
Walter Dnes
Jan 10, 2024, 12:10:05 AMJan 10
to
On Tue, Jan 09, 2024 at 02:54:06PM -0500, Philip Webb wrote
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) :
>
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>"'
>
"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.
>
> 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
> IIRC we both live in/near Toronto, so no doubt Big Bad Bell is
> responsible.
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.
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.
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.
Walter Dnes
Jan 18, 2024, 12:10:05 PMJan 18
to
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
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
Michael
Jan 18, 2024, 1:50:05 PMJan 18
to
set from = "walt...@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.
Michael
Jan 21, 2024, 7:10:10 AMJan 21
to
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
>
> 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 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
> > openssl s_client -connect smtp.ebox.ca\:587 -starttls smtp -showcerts
>
> openssl s_client -connect smtp.ebox.ca\:587 -starttls smtp -showcerts >
>
> 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
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
Jack
Jan 21, 2024, 11:40:05 AMJan 21
to
On 1/21/24 11:09, Walter Dnes wrote:
> On Sun, Jan 21, 2024 at 12:05:45PM +0000, Michael wrote
> getting the same message...
> 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 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
>>
>> 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.
> 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
>> gnutls_handshake: A packet with illegal or unsupported version was received.
> 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?
>
Michael
Jan 21, 2024, 2:30:05 PMJan 21
to
On Sunday, 21 January 2024 16:09:47 GMT Walter Dnes wrote:
> On Sun, Jan 21, 2024 at 12:05:45PM +0000, Michael 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.
> > 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
>
> 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
>
> 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?
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
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.
Walter Dnes
Jan 22, 2024, 3:30:06 PMJan 22
to
On Tue, Jan 09, 2024 at 02:01:34PM -0500, Walter Dnes wrote
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
> 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
> but I'll be needing to authenticate outbound email on port 587 (long
> story).
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.
Walter Dnes
Jan 22, 2024, 5:00:05 PMJan 22
to
On Mon, Jan 22, 2024 at 03:24:44PM -0500, Walter Dnes wrote
muttrc...
set ssl_starttls=no
set ssl_force_tls=no
set smtp_url=smtp://smtp.ebox.ca:587
...and it works, at least on cable.
> 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.
Well, that was easy. *IN MY PARTICULAR CASE* I added 3 lines to
> > 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.
muttrc...
set ssl_starttls=no
set ssl_force_tls=no
set smtp_url=smtp://smtp.ebox.ca:587
...and it works, at least on cable.
Michael
Jan 22, 2024, 5:10:04 PMJan 22
to
they had to connect to the SMTP server from the ISP provisioned block of IP
addresses. Until then SMTP port 25 was in use and username/passwd was not
required - although I recall some ISPs would use a 'POP before SMTP' control
mechanism to make sure only authenticated users on the ISP's POP3 server were
allowed to jump on the ISP's SMTP server.
The STARTTLS mechanism was standardised around the late 90s to introduce
encrypted communication with the server and 'AUTH PLAIN LOGIN' for SMTP was
added as an extension around that time. This was done in response to an
increasing abuse of SMTP servers by miscreants to relay messages for SPAM and
malware alike.
If your ISP *only* offers access from their own block of IPs, do they refuse
access to their SMTP server for legitimate subscribers who move around and
want to send messages from a different network?
Anyway, if you disable TLS encryption then your communication with the server
is sent in the clear. It would be prudent to consider it as a form of public
communication, rather than private. I thought email comms encryption and
server authentication was ubiquitous for decades now, but obviously I am
wrong! :-)
Walter Dnes
Jan 22, 2024, 11:30:04 PMJan 22
to
On Mon, Jan 22, 2024 at 10:08:38PM +0000, Michael wrote
> If your ISP *only* offers access from their own block of IPs, do
> they refuse access to their SMTP server for legitimate subscribers
> who move around and want to send messages from a different network?
I don't know the answer to that one.
> Anyway, if you disable TLS encryption then your communication with
> the server is sent in the clear. It would be prudent to consider it
> as a form of public communication, rather than private. I thought
> email comms encryption and server authentication was ubiquitous for
> decades now, but obviously I am wrong! :-)
The message from my ISP about port 587 said...
>> It has to be set with SSL, without any authentication.
Does SSL help privacy at all? BTW, if mutt does *ANY* external
ccommunication it seems to require the "ssl" USE flag. Trying...
USE="-ssl" emerge -pv mutt
...on my system dies with...
The following REQUIRED_USE flag constraints are unsatisfied:
imap? ( ssl ) pop? ( ssl ) smtp? ( ssl )
This message coming to you via port 587
> If your ISP *only* offers access from their own block of IPs, do
> they refuse access to their SMTP server for legitimate subscribers
> who move around and want to send messages from a different network?
> Anyway, if you disable TLS encryption then your communication with
> the server is sent in the clear. It would be prudent to consider it
> as a form of public communication, rather than private. I thought
> email comms encryption and server authentication was ubiquitous for
> decades now, but obviously I am wrong! :-)
>> It has to be set with SSL, without any authentication.
ccommunication it seems to require the "ssl" USE flag. Trying...
USE="-ssl" emerge -pv mutt
...on my system dies with...
The following REQUIRED_USE flag constraints are unsatisfied:
imap? ( ssl ) pop? ( ssl ) smtp? ( ssl )
This message coming to you via port 587
Michael
Jan 23, 2024, 4:40:05 AMJan 23
to
On Tuesday, 23 January 2024 04:21:13 GMT Walter Dnes wrote:
> The message from my ISP about port 587 said...
>
> >> It has to be set with SSL, without any authentication.
Since gnutls is playing up with mutt, you can try setting USE="-gnutls" and
> The message from my ISP about port 587 said...
>
> >> It has to be set with SSL, without any authentication.
re-emerge mutt to see if it succeeds establishing a connection.
> Does SSL help privacy at all?
Secure Socket Layer (SSL) as it was and its evolved successor Transport Layer
Security (TLS) are cryptographic protocols used to encrypt and authenticate
data transferred between servers and applications. The concept of TLS and use
of TLS certificates is to ensure clients know (can verify) the server they are
connecting with is hosted on the intended domain and data transferred back and
forth has not been tampered with. In addition encryption of the transport
layer allows encapsulated data between client and server to remain private.
Client authentication credentials transferred between two parties over TLS
ensure only legitimate users are allowed to access their data on the server.
Server authentication verifies the legitimacy of the user usually by means of
a username and password, although client TLS certificates, tokens and what not
can be used for the same purpose. The client's IP address can be used as an
additional verification check, but this is usually implemented between static
network end points between machines - e.g. VPN between HQ and satellite
offices.
User authentication based on the mail client's IP address only is a weak
verification mechanism, both because of the potential for IP address spoofing
by malicious actors and because the user may want to retain their privacy from
other hosts who happen to share the same IP address.
> BTW, if mutt does *ANY* external
> ccommunication it seems to require the "ssl" USE flag. Trying...
>
> USE="-ssl" emerge -pv mutt
>
> ...on my system dies with...
>
> The following REQUIRED_USE flag constraints are unsatisfied:
> imap? ( ssl ) pop? ( ssl ) smtp? ( ssl )
$ euse -i ssl
global use flags (searching: ssl)
************************************************************
[+ D ] ssl - Add support for SSL/TLS connections (Secure Socket Layer /
Transport Layer Security)
[snip ...]
This is because TLS is ubiquitous today across web site and email server
implementations. The WWW days of innocence are long gone, if they ever really
existed.
>
> This message coming to you via port 587
encrypted connection is optional and a matter of server implementation.
Depending on how the mail server has been configured, TLS encryption may be
implemented or indeed required on any port conventionally used to send
messages (25, 465, 587, 2525).
Walter Dnes
Jan 23, 2024, 10:50:05 AMJan 23
to
On Tue, Jan 23, 2024 at 09:36:13AM +0000, Michael wrote
> Since gnutls is playing up with mutt, you can try setting USE="-gnutls"
> and re-emerge mutt to see if it succeeds establishing a connection.
If I emerge mutt with USE="-gnutls" and comment out
"set ssl_starttls=no", email fails...
[2024-01-23 09:38:07] Looking up smtp.ebox.ca...
[2024-01-23 09:38:07] Connecting to smtp.ebox.ca...
[2024-01-23 09:38:07] Connected to smtp.ebox.ca:587 on fd=4
[2024-01-23 09:38:07] 4< 220 smtp.ebox.ca ESMTP Postfix (Debian/GNU)
[2024-01-23 09:38:07] 4> EHLO waltdnes.org
[2024-01-23 09:38:07] 4< 250-smtp.ebox.ca
[2024-01-23 09:38:07] 4< 250-PIPELINING
[2024-01-23 09:38:07] 4< 250-SIZE 20000000
[2024-01-23 09:38:07] 4< 250-VRFY
[2024-01-23 09:38:07] 4< 250-ETRN
[2024-01-23 09:38:07] 4< 250-STARTTLS
[2024-01-23 09:38:07] 4< 250-ENHANCEDSTATUSCODES
[2024-01-23 09:38:07] 4< 250-8BITMIME
[2024-01-23 09:38:07] 4< 250 DSN
[2024-01-23 09:38:07] 4> STARTTLS
[2024-01-23 09:38:07] 4< 220 2.0.0 Ready to start TLS
[2024-01-23 09:38:07] ssl_load_certificates: loading trusted certificates
[2024-01-23 09:38:07] mutt_ssl_starttls: Error loading trusted certificates
[2024-01-23 09:38:07] SSL failed: error:0A000102:SSL routines::unsupported protocol
[2024-01-23 09:38:08] Could not negotiate TLS connection
ssl_starttls (and ssl_force_tls) default to "yes" in muttrc. If
ssl_starttls and ssl_force_tls are not explicitly set to "no", mutt
*WILL* attempt a TLS connection if advertised. Whem mutt is built with
USE="-gnutls" and attempts a TLS connection, let's just say "it does not
end well".
tldr;
It's easier for me to build in gnutls support and then (un)comment one
or two lines in ~/.mutt/muttrc as needed rather than...
* pop up an xterm
* su - (and enter password to root)
* emerge mutt with appropriate flag(s)
* exit to regular user
> Since gnutls is playing up with mutt, you can try setting USE="-gnutls"
> and re-emerge mutt to see if it succeeds establishing a connection.
"set ssl_starttls=no", email fails...
[2024-01-23 09:38:07] Looking up smtp.ebox.ca...
[2024-01-23 09:38:07] Connecting to smtp.ebox.ca...
[2024-01-23 09:38:07] Connected to smtp.ebox.ca:587 on fd=4
[2024-01-23 09:38:07] 4< 220 smtp.ebox.ca ESMTP Postfix (Debian/GNU)
[2024-01-23 09:38:07] 4> EHLO waltdnes.org
[2024-01-23 09:38:07] 4< 250-smtp.ebox.ca
[2024-01-23 09:38:07] 4< 250-PIPELINING
[2024-01-23 09:38:07] 4< 250-SIZE 20000000
[2024-01-23 09:38:07] 4< 250-VRFY
[2024-01-23 09:38:07] 4< 250-ETRN
[2024-01-23 09:38:07] 4< 250-STARTTLS
[2024-01-23 09:38:07] 4< 250-ENHANCEDSTATUSCODES
[2024-01-23 09:38:07] 4< 250-8BITMIME
[2024-01-23 09:38:07] 4< 250 DSN
[2024-01-23 09:38:07] 4> STARTTLS
[2024-01-23 09:38:07] 4< 220 2.0.0 Ready to start TLS
[2024-01-23 09:38:07] ssl_load_certificates: loading trusted certificates
[2024-01-23 09:38:07] mutt_ssl_starttls: Error loading trusted certificates
[2024-01-23 09:38:07] SSL failed: error:0A000102:SSL routines::unsupported protocol
[2024-01-23 09:38:08] Could not negotiate TLS connection
ssl_starttls (and ssl_force_tls) default to "yes" in muttrc. If
ssl_starttls and ssl_force_tls are not explicitly set to "no", mutt
*WILL* attempt a TLS connection if advertised. Whem mutt is built with
USE="-gnutls" and attempts a TLS connection, let's just say "it does not
end well".
tldr;
It's easier for me to build in gnutls support and then (un)comment one
or two lines in ~/.mutt/muttrc as needed rather than...
* pop up an xterm
* su - (and enter password to root)
* emerge mutt with appropriate flag(s)
* exit to regular user
Michael
Jan 23, 2024, 11:20:04 AMJan 23
to
forgiving. :-(
> ssl_starttls (and ssl_force_tls) default to "yes" in muttrc. If
> ssl_starttls and ssl_force_tls are not explicitly set to "no", mutt
> *WILL* attempt a TLS connection if advertised. Whem mutt is built with
> USE="-gnutls" and attempts a TLS connection, let's just say "it does not
> end well".
server. From the logs you have shared we can safely guess this is because the
Root CA used by the server is still using a SHA1 hash.
> tldr;
>
> It's easier for me to build in gnutls support and then (un)comment one
> or two lines in ~/.mutt/muttrc as needed rather than...
>
> * pop up an xterm
> * su - (and enter password to root)
> * emerge mutt with appropriate flag(s)
> * exit to regular user
in this case. You can also try to set deprecated TLS protocols in ~/.muttrc
to see if this will allow for a successful connection:
http://mutt.org/doc/manual/#ssl-use-tlsv1
You had a good crack at this, but TBH it would be easier and safer to find an
email hosting company who use up to date TLS certificates. ;-)
Walter Dnes
Jan 23, 2024, 2:10:05 PMJan 23
to
On Tue, Jan 23, 2024 at 04:12:05PM +0000, Michael wrote
> You can also try to set deprecated TLS protocols in ~/.muttrc
> to see if this will allow for a successful connection:
>
> http://mutt.org/doc/manual/#ssl-use-tlsv1
Thanks. I commented out the "no" lines. TLS 1.1 failed, but TLS 1.0
seems to work...
# set ssl_starttls=no
# set ssl_force_tls=no
set ssl_use_tlsv1=yes
set smtp_url=smtp://smtp.ebox.ca:587
> You had a good crack at this, but TBH it would be easier and safer to
> find an email hosting company who use up to date TLS certificates. ;-)
I currently use cotse.net to handle incoming email. It's served me
well, allowing me to keep the same email address over the years as I've
changed ISPs. I could do outbound email through them, but I don't like
webmail interfaces. Notice the mention of "mutt" in the subject.
This post is coming to you via port 587 *VIA FIBRE*... wheeeee! The
support desk phoned this morning, and we went spelunking through the
config menus of the fibre modem, and set it up.
> You can also try to set deprecated TLS protocols in ~/.muttrc
> to see if this will allow for a successful connection:
>
> http://mutt.org/doc/manual/#ssl-use-tlsv1
seems to work...
# set ssl_starttls=no
# set ssl_force_tls=no
set ssl_use_tlsv1=yes
set smtp_url=smtp://smtp.ebox.ca:587
> You had a good crack at this, but TBH it would be easier and safer to
> find an email hosting company who use up to date TLS certificates. ;-)
well, allowing me to keep the same email address over the years as I've
changed ISPs. I could do outbound email through them, but I don't like
webmail interfaces. Notice the mention of "mutt" in the subject.
This post is coming to you via port 587 *VIA FIBRE*... wheeeee! The
support desk phoned this morning, and we went spelunking through the
config menus of the fibre modem, and set it up.
Michael
Jan 23, 2024, 4:50:05 PMJan 23
to
On Tuesday, 23 January 2024 19:09:19 GMT Walter Dnes wrote:
> On Tue, Jan 23, 2024 at 04:12:05PM +0000, Michael wrote
>
> > You can also try to set deprecated TLS protocols in ~/.muttrc
> > to see if this will allow for a successful connection:
> >
> > http://mutt.org/doc/manual/#ssl-use-tlsv1
>
> Thanks. I commented out the "no" lines. TLS 1.1 failed, but TLS 1.0
> seems to work...
>
> # set ssl_starttls=no
> # set ssl_force_tls=no
> set ssl_use_tlsv1=yes
> set smtp_url=smtp://smtp.ebox.ca:587
>
> > You had a good crack at this, but TBH it would be easier and safer to
> > find an email hosting company who use up to date TLS certificates. ;-)
>
> I currently use cotse.net to handle incoming email. It's served me
> well, allowing me to keep the same email address over the years as I've
> changed ISPs. I could do outbound email through them, but I don't like
> webmail interfaces. Notice the mention of "mutt" in the subject.
O_O
> On Tue, Jan 23, 2024 at 04:12:05PM +0000, Michael wrote
>
> > You can also try to set deprecated TLS protocols in ~/.muttrc
> > to see if this will allow for a successful connection:
> >
> > http://mutt.org/doc/manual/#ssl-use-tlsv1
>
> Thanks. I commented out the "no" lines. TLS 1.1 failed, but TLS 1.0
> seems to work...
>
> # set ssl_starttls=no
> # set ssl_force_tls=no
> set ssl_use_tlsv1=yes
> set smtp_url=smtp://smtp.ebox.ca:587
>
> > You had a good crack at this, but TBH it would be easier and safer to
> > find an email hosting company who use up to date TLS certificates. ;-)
>
> I currently use cotse.net to handle incoming email. It's served me
> well, allowing me to keep the same email address over the years as I've
> changed ISPs. I could do outbound email through them, but I don't like
> webmail interfaces. Notice the mention of "mutt" in the subject.
STOP RIGHT THERE!
http://cotse.net/support.html
They offer SMTP on any number of ports AND require TLS authentication. No
need to dance around deprecated hash algos and certificates.
Remove the 'ssl_use_tlsv1=yes' directive.
For SMTP server use:
set smtp_url = "smtp://Your_Us...@www.cotse.net:465"
You can use port 465 without STARTTLS. Mutt will negotiate an encrypted
connection over TLS right off the bat.
Use your username and password to login, as you do for POP3/IMAP4. Job done.
> This post is coming to you via port 587 *VIA FIBRE*... wheeeee! The
> support desk phoned this morning, and we went spelunking through the
> config menus of the fibre modem, and set it up.
to receive and send messages. They appear to be running a more up to date
professional setup.
Walter Dnes
Jan 23, 2024, 9:20:05 PMJan 23
to
I'm back after several minutes backing up to two USB drives.
On Tue, Jan 23, 2024 at 09:41:16PM +0000, Michael wrote
Just one change... change "smtp://" to "smtps://", otherwise mutt
won't connect...
set smtp_pass="cotse_password"
set smtp_url="smtps://cotse_...@www.cotse.net:465"
Sending a test message I got a prompt...
This certificate belongs to:
Sectigo RSA Domain Validation Secure Server CA
Sectigo Limited
Salford Greater Manchester GB
yada, yada, yada
It asked whether I wanted to (r)eject, accept (o)nce, accept (a)lways
and I chose always.
This post is coming to you via port 587 via fibre and via cotse.net.
Thank you very much. I couldn't have done it without your deatailed help.
On Tue, Jan 23, 2024 at 09:41:16PM +0000, Michael wrote
Just one change... change "smtp://" to "smtps://", otherwise mutt
won't connect...
set smtp_pass="cotse_password"
set smtp_url="smtps://cotse_...@www.cotse.net:465"
Sending a test message I got a prompt...
This certificate belongs to:
Sectigo RSA Domain Validation Secure Server CA
Sectigo Limited
Salford Greater Manchester GB
yada, yada, yada
It asked whether I wanted to (r)eject, accept (o)nce, accept (a)lways
and I chose always.
This post is coming to you via port 587 via fibre and via cotse.net.
Thank you very much. I couldn't have done it without your deatailed help.
Michael
Jan 24, 2024, 4:40:06 AMJan 24
to
On Wednesday, 24 January 2024 02:19:29 GMT Walter Dnes wrote:
> I'm back after several minutes backing up to two USB drives.
>
> On Tue, Jan 23, 2024 at 09:41:16PM +0000, Michael wrote
>
> > For SMTP server use:
> >
> > set smtp_url = "smtp://Your_Us...@www.cotse.net:465"
>
> Just one change... change "smtp://" to "smtps://", otherwise mutt
> won't connect...
>
> set smtp_pass="cotse_password"
> set smtp_url="smtps://cotse_...@www.cotse.net:465"
Yes, my bad. The prefix smtps:// is needed to indicate an explicit TLS
> I'm back after several minutes backing up to two USB drives.
>
> On Tue, Jan 23, 2024 at 09:41:16PM +0000, Michael wrote
>
> > For SMTP server use:
> >
> > set smtp_url = "smtp://Your_Us...@www.cotse.net:465"
>
> Just one change... change "smtp://" to "smtps://", otherwise mutt
> won't connect...
>
> set smtp_pass="cotse_password"
> set smtp_url="smtps://cotse_...@www.cotse.net:465"
connection.
> Sending a test message I got a prompt...
>
> This certificate belongs to:
> Sectigo RSA Domain Validation Secure Server CA
> Sectigo Limited
>
> Salford Greater Manchester GB
> yada, yada, yada
$ openssl s_client -connect www.cotse.net\:465 -showcerts
CONNECTED(00000003)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network,
CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN
= Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = www.cotse.net
verify return:1
The "Sectigo RSA Domain Validation Secure Server CA" is an intermediate CA
certificate and as it happens it is not available in the OS certificate store
/etc/ssl/certs/ where trusted Root CAs reside. Theoretically, mutt via gnutls
should check the issuer of the intermediate certificate which is "USERTrust
RSA Certification Authority", find this certificate in the OS' store of
trusted Root CAs and consequently accept as trusted any certificates in the
chain signed by this Root CA.
I don't know why this doesn't function as I describe above. Practically it
seems mutt may need to be directed to accept all certificates in a chain as
trusted.
http://www.mutt.org/doc/manual/#certificate-file
You could try copying the "USERTrust RSA Certification Authority" in your
local mutt certificates directory, or copying just the intermediate CA
certificate "Sectigo RSA Domain Validation Secure Server CA".
> It asked whether I wanted to (r)eject, accept (o)nce, accept (a)lways
> and I chose always.
local mutt certificates directory.
> This post is coming to you via port 587 via fibre and via cotse.net.
> Thank you very much. I couldn't have done it without your deatailed help.
0 new messages