Setting up General Email (IMAP, SMTP) fails

Bug Reports
64

Google-developers-space-thingy declares :
The outgoing SMTP server, smtp.gmail.com, supports TLS. If your client begins with plain text, before issuing the STARTTLS command, use port 465 (for SSL), or port 587 (for TLS).

I guess @Seven.of.nine that is what you mean by ‘plain’ , I don’t fully understand this yet (which is fine) but fact is that ‘plain’ is no option the email app. The secure connection field can only be switched between “not in use” / “SSL” / “StartTLS”.

I’ve tried settings for both port numbers several times and kept checking if incoming mail
keeps working (so checking for internet so to speak). Incoming works , outgoing not :man_shrugging:

@nshiell I tried rebooting too after changes but no success.

Thank you both for your suggestions though :+1:

65

So, both IMAP and SMTP can operate in three modes as far as encryption of the connection is concerned:

  • no encryption
  • SSL encryption
  • “StartTLS”

The first two should be be clear, the third one is a bit of a hybrid. It means the conversation starts unencrypted, but at one point the client issues a command called StartTLS. This causes the rest of the connection to become encrypted.

The SSL variant requires a specific port which can only work in SSL mode.
The other two can use the same port because the initial connection is always unencrypted.

For IMAP, SSL is usually on 993, and plain/starttls is 143.
For SMTP, SSL is usually on 465, and the others either 25 or 587. 25 is blocked in many networks, so should be avoided.

(And just for completeness: the term SSL should not be used any more really, it is nowadays all TLS. But it serves to distinguish between SSL/TLS and StartTLS which are different things.)

2 Likes
66

Ahaah now I understand this, thank you :slight_smile:

I figured that because SFOS would set the most obvious as an initial template, right ?

So this implies that I select TLS by hitting SSL in the drop-down-menu ? :yum:

Anyway, it seems clear that not many options can be used as alternative and if one has
tried all of them without success → one has a problem :sweat_smile:

67

The email IMAP and CalDAV calendars setup is very buggy

Sorry to hear that. If you describe a procedure that one can reproduce your errors, they can be fixed. Most of the stack for it is open source. The initial setting up is in the close source parts, but it’s very restricted and accessible with a NDA. So can be fixed also.

1 Like
68

Having recently set up 4 other accounts after reinstalling SFOS, I am unable to add a newly created account with gmx.com, yet, two of my four other accounts are also with gmx.com and work perfectly, I’ve tried numerous times. I know my settings are correct.

Also to note, my new account will not set up in Outlook on Windows, so perhaps the problem is not necessarily an SFOS problem, yet the account IS working if signed into via the GMX portal.

Enshitification has finally infected everything.

1 Like
69

Agree! (20 characters)
edit: Why can’t ‘big’ mail providers work the same as clean set’up mail servers, they work perfect on SFOS.

TLDR:
I had 2 mail accounts, one at a small + clean provider and one at GMX.
I always got abt. 5 more or less harmless spam mails per day on every account.
Since I deleted the GMX account some weeks ago, since the same hour spam stopped at the ‘clean’ account. Since this time no more spam there.
And:
Exactly the span of time, while a DHL parcel was on the way to me (few months ago), this week a huge amount of spam and phishing mails came about my parcel held back somewhere for some reasons, I should contact some addresses with phantasy server names… I ignored, and thought by myself, if parcel will not come, I’ll complain by the sender but surely will contact nobody by Internet. Few days later parcel came to me without any issues.
Do the spammers hack parcel services server systems in real time and therefore know exactly who’s waiting for a parcel at a moment?