Mailing List Archive

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! :-)

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

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

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

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

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

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.

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

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