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

[Michael <confabulate@kintzios.com>]

[-- 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 --]