[gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?

[gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?

[Walter Dnes]

  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

Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?

[Philip Webb]

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

Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?

[Walter Dnes]

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

Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?

[Walter Dnes]

  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

Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2714 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?

[Walter Dnes]

[-- Attachment #1: Type: text/plain, Size: 2825 bytes --]

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

[-- Attachment #2: logs.tgz --]
[-- Type: application/x-gtar, Size: 6209 bytes --]

Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 4528 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?

[Walter Dnes]

[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

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

[-- Attachment #2: certificates --]
[-- Type: text/plain, Size: 7108 bytes --]

-----BEGIN CERTIFICATE-----
MIIGgDCCBWigAwIBAgIIQdcTd20TTxAwDQYJKoZIhvcNAQELBQAwgbQxCzAJBgNV
BAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQHEwpTY290dHNkYWxlMRow
GAYDVQQKExFHb0RhZGR5LmNvbSwgSW5jLjEtMCsGA1UECxMkaHR0cDovL2NlcnRz
LmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvMTMwMQYDVQQDEypHbyBEYWRkeSBTZWN1
cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwHhcNMjMwOTI2MDEwMDI1WhcN
MjQxMDI3MDEwMDI1WjAUMRIwEAYDVQQDDAkqLmVib3guY2EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC1kgJlaAqSUNfZd2jPfxSlH0HTzvFV344iJdd3
zf01XwSySxtAKB3bwrmxfq0ppmVU4CTlj1IOTaY7uA3Fpy5V0CAE38HOpT/xsv1n
7ZXAm7jVA8UOJbFMtCwCtLArhEeGZS8ssrO51uzZquj6O2zCQeoG7cYqeQTh0Z3X
x1DmsdP5Tvyot82p3SKiCoFurk/ZIMXeDbG3K+Vxw+wiFgmYYl1rBAOJpyqxIwuX
NFlkNCU2K7M2LqohyO10FI/RJOn0hwuY+t7a6kZbNKLGWuuUXg29Y9TrqUXAa5yN
mmJtTD6UsHfGKPZN5n1GlqgNSUDlxLKBedA7gTzHQKh+BYBhAgMBAAGjggMzMIID
LzAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAO
BgNVHQ8BAf8EBAMCBaAwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5nb2Rh
ZGR5LmNvbS9nZGlnMnMxLTk0MDUuY3JsMF0GA1UdIARWMFQwSAYLYIZIAYb9bQEH
FwEwOTA3BggrBgEFBQcCARYraHR0cDovL2NlcnRpZmljYXRlcy5nb2RhZGR5LmNv
bS9yZXBvc2l0b3J5LzAIBgZngQwBAgEwdgYIKwYBBQUHAQEEajBoMCQGCCsGAQUF
BzABhhhodHRwOi8vb2NzcC5nb2RhZGR5LmNvbS8wQAYIKwYBBQUHMAKGNGh0dHA6
Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9nZGlnMi5jcnQw
HwYDVR0jBBgwFoAUQMK9J47MNIMwojPX+2yz8LQsgM4wHQYDVR0RBBYwFIIJKi5l
Ym94LmNhggdlYm94LmNhMB0GA1UdDgQWBBQKTRI2+yZaO2QIMLlRwVy3A5EslTCC
AX4GCisGAQQB1nkCBAIEggFuBIIBagFoAHUA7s3QZNXbGs7FXLedtM0TojKHRny8
7N7DUUhZRnEftZsAAAGKzwBtGQAABAMARjBEAiB+c8AeqWVcH6tLIN3K+jxvyrcS
bezMfVwxregY56O9uwIgfdjEFhw0w7dvv6O7kyrYFLXd1KmLtZZUBkg/pSr72ScA
dgBIsONr2qZHNA/lagL6nTDrHFIBy1bdLIHZu7+rOdiEcwAAAYrPAG3/AAAEAwBH
MEUCIGniWz36pvx9BThv4yxeEqoAk1pEqJz9vggQfm1nsABKAiEA4DE0bNlpa90J
JBpJk+ane6GP3Ycu0zG/kfjPRKGWaT4AdwDatr9rP7W2Ip+bwrtca+hwkXFsu1GE
hTS9pD0wSNf7qwAAAYrPAG55AAAEAwBIMEYCIQCnqbkMcFiLX1Gc9EHlyo4Rm/T7
pCmjJV1ylgVQhk5tMQIhALGmRhmJmH77RRh0+CBKX+MZ6EtKBnci+j6jGHus7Xj4
MA0GCSqGSIb3DQEBCwUAA4IBAQBK852eVZVAZmuKFg/37ywvp1p3Otq1Iy6093pR
QEoKUN5OVxLcAYJTcQSrGMZdytVNGuOe9F3mm2tP4NxOT32ERyowAFx3DOIFIJRP
6XDO9V2tUgoJ4hxMdNnzoAcnXh/naTLtWD29OpjEzsMYjFQuaeeKXa0Nk4/1bUhm
Nugmmm3z2DLOumVKILzi/uZLDYdrO4vOkIxXLgBdHZFV+6ZZVR26bffvS3q3owRG
8d/eXulLowCoblX8PbNBedRVll18+t2j/FzVD7N7L7qF5076/LODbfk6fRHEXN/w
65NjrQ1RiRekUHXMjFrlTraSIEWQOAaGaDCOmcOyjcjfuk7/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIE0DCCA7igAwIBAgIBBzANBgkqhkiG9w0BAQsFADCBgzELMAkGA1UEBhMCVVMx
EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAYBgNVBAoT
EUdvRGFkZHkuY29tLCBJbmMuMTEwLwYDVQQDEyhHbyBEYWRkeSBSb290IENlcnRp
ZmljYXRlIEF1dGhvcml0eSAtIEcyMB4XDTExMDUwMzA3MDAwMFoXDTMxMDUwMzA3
MDAwMFowgbQxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQH
EwpTY290dHNkYWxlMRowGAYDVQQKExFHb0RhZGR5LmNvbSwgSW5jLjEtMCsGA1UE
CxMkaHR0cDovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvMTMwMQYDVQQD
EypHbyBEYWRkeSBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC54MsQ1K92vdSTYuswZLiBCGzD
BNliF44v/z5lz4/OYuY8UhzaFkVLVat4a2ODYpDOD2lsmcgaFItMzEUz6ojcnqOv
K/6AYZ15V8TPLvQ/MDxdR/yaFrzDN5ZBUY4RS1T4KL7QjL7wMDge87Am+GZHY23e
cSZHjzhHU9FGHbTj3ADqRay9vHHZqm8A29vNMDp5T19MR/gd71vCxJ1gO7GyQ5HY
pDNO6rPWJ0+tJYqlxvTV0KaudAVkV4i1RFXULSo6Pvi4vekyCgKUZMQWOlDxSq7n
eTOvDCAHf+jfBDnCaQJsY1L6d8EbyHSHyLmTGFBUNUtpTrw700kuH9zB0lL7AgMB
AAGjggEaMIIBFjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNV
HQ4EFgQUQMK9J47MNIMwojPX+2yz8LQsgM4wHwYDVR0jBBgwFoAUOpqFBxBnKLbv
9r0FQW4gwZTaD94wNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8v
b2NzcC5nb2RhZGR5LmNvbS8wNQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2NybC5n
b2RhZGR5LmNvbS9nZHJvb3QtZzIuY3JsMEYGA1UdIAQ/MD0wOwYEVR0gADAzMDEG
CCsGAQUFBwIBFiVodHRwczovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkv
MA0GCSqGSIb3DQEBCwUAA4IBAQAIfmyTEMg4uJapkEv/oV9PBO9sPpyIBslQj6Zz
91cxG7685C/b+LrTW+C05+Z5Yg4MotdqY3MxtfWoSKQ7CC2iXZDXtHwlTxFWMMS2
RJ17LJ3lXubvDGGqv+QqG+6EnriDfcFDzkSnE3ANkR/0yBOtg2DZ2HKocyQetawi
DsoXiWJYRBuriSUBAA/NxBti21G00w9RKpv0vHP8ds42pM3Z2Czqrpv1KrKQ0U11
GIo/ikGQI31bS/6kA1ibRrLDYGCD+H1QQc7CoZDDu+8CL9IVVO5EFdkKrqeKM+2x
LXY2JtwE65/3YR8V3Idv7kaWKK2hJn0KCacuBKONvPi8BDAB
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEfTCCA2WgAwIBAgIDG+cVMA0GCSqGSIb3DQEBCwUAMGMxCzAJBgNVBAYTAlVT
MSEwHwYDVQQKExhUaGUgR28gRGFkZHkgR3JvdXAsIEluYy4xMTAvBgNVBAsTKEdv
IERhZGR5IENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMTAx
MDcwMDAwWhcNMzEwNTMwMDcwMDAwWjCBgzELMAkGA1UEBhMCVVMxEDAOBgNVBAgT
B0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAYBgNVBAoTEUdvRGFkZHku
Y29tLCBJbmMuMTEwLwYDVQQDEyhHbyBEYWRkeSBSb290IENlcnRpZmljYXRlIEF1
dGhvcml0eSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv3Fi
CPH6WTT3G8kYo/eASVjpIoMTpsUgQwE7hPHmhUmfJ+r2hBtOoLTbcJjHMgGxBT4H
Tu70+k8vWTAi56sZVmvigAf88xZ1gDlRe+X5NbZ0TqmNghPktj+pA4P6or6KFWp/
3gvDthkUBcrqw6gElDtGfDIN8wBmIsiNaW02jBEYt9OyHGC0OPoCjM7T3UYH3go+
6118yHz7sCtTpJJiaVElBWEaRIGMLKlDliPfrDqBmg4pxRyp6V0etp6eMAo5zvGI
gPtLXcwy7IViQyU0AlYnAZG0O3AqP26x6JyIAX2f1PnbU21gnb8s51iruF9G/M7E
GwM8CetJMVxpRrPgRwIDAQABo4IBFzCCARMwDwYDVR0TAQH/BAUwAwEB/zAOBgNV
HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFDqahQcQZyi27/a9BUFuIMGU2g/eMB8GA1Ud
IwQYMBaAFNLEsNKR1EwRcbNhyz2h/t2oatTjMDQGCCsGAQUFBwEBBCgwJjAkBggr
BgEFBQcwAYYYaHR0cDovL29jc3AuZ29kYWRkeS5jb20vMDIGA1UdHwQrMCkwJ6Al
oCOGIWh0dHA6Ly9jcmwuZ29kYWRkeS5jb20vZ2Ryb290LmNybDBGBgNVHSAEPzA9
MDsGBFUdIAAwMzAxBggrBgEFBQcCARYlaHR0cHM6Ly9jZXJ0cy5nb2RhZGR5LmNv
bS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAWQtTvZKGEacke+1bMc8d
H2xwxbhuvk679r6XUOEwf7ooXGKUwuN+M/f7QnaF25UcjCJYdQkMiGVnOQoWCcWg
OJekxSOTP7QYpgEGRJHjp2kntFolfzq3Ms3dhP8qOCkzpN1nsoX+oYggHFCJyNwq
9kIDN0zmiN/VryTyscPfzLXs4Jlet0lUIDyUGAzHHFIYSaRt4bNYC8nY7NmuHDKO
KHAN4v6mF56ED71XcLNa6R+ghlO773z/aQvgSMO3kwvIClTErF0UZzdsyqUvMQg3
qm5vjLyb4lddJIGvl5echK1srDdMZvNhkREg5L4wn3qkKQmw4TRfZHcYQFHfjDCm
rw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEADCCAuigAwIBAgIBADANBgkqhkiG9w0BAQUFADBjMQswCQYDVQQGEwJVUzEh
MB8GA1UEChMYVGhlIEdvIERhZGR5IEdyb3VwLCBJbmMuMTEwLwYDVQQLEyhHbyBE
YWRkeSBDbGFzcyAyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA0MDYyOTE3
MDYyMFoXDTM0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRo
ZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3Mg
MiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN
ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XCA
PVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux6w
wdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLOtXi
EqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWoriMY
avx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZEewo+
YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjgcAwgb0wHQYDVR0OBBYEFNLE
sNKR1EwRcbNhyz2h/t2oatTjMIGNBgNVHSMEgYUwgYKAFNLEsNKR1EwRcbNhyz2h
/t2oatTjoWekZTBjMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYVGhlIEdvIERhZGR5
IEdyb3VwLCBJbmMuMTEwLwYDVQQLEyhHbyBEYWRkeSBDbGFzcyAyIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5ggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQAD
ggEBADJL87LKPpH8EsahB4yOd6AzBhRckB4Y9wimPQoZ+YeAEW5p5JYXMP80kWNy
OO7MHAGjHZQopDH2esRU1/blMVgDoszOYtuURXO1v0XJJLXVggKtI3lpjbi2Tc7P
TMozI+gciKqdi0FuFskg5YmezTvacPd+mSYgFFQlq25zheabIZ0KbIIOqPjCDPoQ
HmyW74cNxA9hi63ugyuV+I6ShHI56yDqg+2DzZduCLzrTia2cyvk0/ZM/iZx4mER
dEr/VxqHD3VILs9RaRegAhJhldXRQLIQTO7ErBBDpqWeCtWVYpoNz4iCxTIM5Cuf
ReYNnyicsbkqWletNw+vHX/bvZ8=
-----END CERTIFICATE-----

Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?

[Jack]

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

Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 4083 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] [OT] Anyone running mutt outboung smtp on port 587?

[Walter Dnes]

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

[gentoo-user] [SOLVED] [OT] Anyone running mutt outboung smtp on port 587?

[Walter Dnes]

On Mon, Jan 22, 2024 at 03:24:44PM -0500, Walter Dnes wrote
> 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
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.

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

Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outboung smtp on port 587?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

On Monday, 22 January 2024 21:52:03 GMT Walter Dnes wrote:
> On Mon, Jan 22, 2024 at 03:24:44PM -0500, Walter Dnes wrote
> 
> > 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
> 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.

Some 20-25 years ago ISPs would offer email services to their customers, but 
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!  :-)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outboung smtp on port 587?

[Walter Dnes]

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

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

Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outboung smtp on port 587?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]

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 
re-emerge mutt to see if it succeeds establishing a connection.


>   Does SSL help privacy at all?  

Yes.  Data transferred between client and server will be encrypted.

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 )

The SSL flag on mutt ensures the package is compiled with TLS support:

 $ 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

Port 587 is used for message submission as per RFC6409, using ESMTP, but an 
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).

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outbound smtp on port 587?

[Walter Dnes]

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

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

Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outbound smtp on port 587?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]

On Tuesday, 23 January 2024 15:47:28 GMT Walter Dnes wrote:
> 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

OpenSSL bails out just as gnutls did.  I was hoping it could have been more 
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".

Both OpenSSL and GnuTLS fail to negotiate an encrypted connection with the 
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

You can revert/keep mutt compiled with USE="gnutls".  It makes no difference 
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.  ;-)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outbound smtp on port 587?

[Walter Dnes]

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.

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

Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outbound smtp on port 587?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]

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

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

It doesn't matter what connection/IP address you use to authenticate on cotse 
to receive and send messages.  They appear to be running a more up to date 
professional setup.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outbound smtp on port 587?

[Walter Dnes]

  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_User_Name@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_userID@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.

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

Re: [gentoo-user] [SOLVED] [OT] Anyone running mutt outbound smtp on port 587?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]

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_User_Name@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_userID@www.cotse.net:465"

Yes, my bad.  The prefix smtps:// is needed to indicate an explicit TLS 
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

This is the intermediate certificate the server's certificate is signed with:

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

Your 'accept (a)lways' command would have stored this certificate in your 
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.

Glad you got it sorted.  :-)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]