Is STARTTLS actually working?

[#1]

A long time ago I set up workarounds to secure my email while PlusNet faffed about not implementing SSL/TLS. I'm now catching up and simplifying stuff so that I use the PlusNet servers directly. I'm using the Outlook desktop program.

When I set it to Security:None on Port 25 (outgoing), emails are reported as Received by PlusNet with ESMTPA (Authenticated) and show X-AUTH: /username/@:2500 i.e. port 25 with two zeroes.

When I set it to Security:SSL/TLS on Port 465, emails are reported as Received with ESMTPSA (Secured and Authenticated) and show  X-AUTH: /username/@:46500. As expected.

When I set it to Security:STARTTLS on Port 587, emails are reported as Received with ESMTPA and show X-AUTH: /username/@:2500 i.e. the same as No Security.

So: is STARTTLS actually working, or does it fallback to Port 25? Or are the headers not reporting correctly?

[#2]

I could not find a definition for X-AUTH.  There are though lots of references to...

• X-AUTH-TOKEN
• X-AUTH-METHOD
• X-AUTH-USERNAME
• X-AUTH-KEY
• ...etc

Can you reference a standard for X-AUTH?

Also port 465 is deprecated.

How much confidence can be set upon X Headers?

Understanding Email Headers – ClickDimensions Support

X-Headers

X-headers are email headers that are added into the email in addition to the standard headers, such as the To, From, and Subject, according to the specific needs of the sender. Mailbox providers also add X-headers to email for things such as SPF, DKIM and DMARC authentication results, spam filter information, and more. X-headers have traditionally started with an X to denote that the value is experimental or an extension of the standard header. This means any header Key that starts with an “X-“ probably relates to processing by proprietary systems and adheres to little standardization.

[#3]

@SilverE - those headers are nothing to do with TLS. They're related to SMTP authentication and the port number is internal to the Plusnet mail platform.

For TLS you need to be looking at the header where a received email is handed over by the Plusnet relays (avasout) to the next MTA in the chain e.g: -

Received: from avasout-peh-003.plus.net (avasout-peh-003.plus.net. [212.159.14.19])
        by mx.google.com with ESMTPS id g18-20020a5d5412000000b002c55fc66705si10662650wrv.997.2023.03.06.23.47.50
        for <redacted>
        (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);

[#4]

@bobpullen I'm looking at the connection between my PC and your server, not the onwards transmission. As I said, when I set Outlook to use STARTTLS the Received: header generated by your server (which does not give its own identity) shows ESMTPA, not ESMTPSA - as I said above. Thus:

Received: from xxxx ([IP4.N.N.N])
by smtp with ESMTPA
id yyyyyyyyyyyy; Mon, 06 Mar 2023 23:00:45 +0000

So - as I understand it - it's being reported as Authenticated (yes, I gave my username and password) but not Secured. Is that the case?

This is the key point, rather than the X-AUTH header.  I realise that that is your local info header (with the X-  prefix) but it would be good if it were consistent.

[#5 · Accepted solution]

STARTTLS works for me. If it wasn't your email client should complain anyway.
I have just done a test at home and looked at the traffic through my router, when sending from K9 mail on a phone through wifi.

Client SMTP set to "no encryption", I can of course read the traffic:

...
15:39:53.660099 IP relay.plus.net.587 > mobiledevice.56600: Flags [P.], seq 1:42, ack 1, win 229, length 41
E..Q..@.5.T... k...w.K....F.#7.fP.......220 avasout-ptp-004 smtp relay.plus.net
...
15:39:53.712483 IP mobiledevice.56600 > relay.plus.net.587: Flags [P.], seq 1:19, ack 42, win 343, length 18
E..:.m@.@..%...w.. k...K#7.f..F.P..Wq...EHLO [127.0.0.1]
...
15:39:53.732921 IP relay.plus.net.587 > mobiledevice.56600: Flags [P.], seq 42:208, ack 19, win 229, length 166
E.....@.5.T!.. k...w.K....F.#7.xP.......250-avasout-ptp-004 hello [51.6.x.y], pleased to meet you 250-HELP
250-AUTH LOGIN PLAIN
250-SIZE 104857600
250-PIPELINING
250-8BITMIME
250-STARTTLS
250 OK

15:39:53.738440 IP mobiledevice.56600 > relay.plus.net.587: Flags [P.], seq 19:72, ack 208, win 347, length 53
E..].n@.@......w.. k...K#7.x..GxP..[....AUTH PLAIN AG......

15:39:53.780107 IP relay.plus.net.587 > mobiledevice.56600: Flags [P.], seq 208:242, ack 72, win 229, length 34
E..J..@.5.T... k...w.K....Gx#7..P.......235 ... authentication succeeded

15:39:53.783732 IP mobiledevice.56600 > relay.plus.net.587: Flags [P.], seq 72:122, ack 242, win 347, length 50
E..Z.o@.@......w.. k...K#7....G.P..[k...MAIL FROM:<me@account.plus.com> BODY=8BITMIME

15:39:53.809448 IP relay.plus.net.587 > mobiledevice.56600: Flags [P.], seq 242:282, ack 122, win 229, length 40
E..P..@.5.T... k...w.K....G.#7..P...x...250 <me@account.plus.com> sender ok

15:39:53.811935 IP mobiledevice.56600 > relay.plus.net.587: Flags [P.], seq 122:157, ack 282, win 347, length 35
E..K.p@.@......w.. k...K#7....G.P..[....RCPT TO:<me@gmail.com>

15:39:53.833844 IP relay.plus.net.587 > mobiledevice.56600: Flags [P.], seq 282:326, ack 157, win 229, length 44
E..T..@.5.T... k...w.K....G.#7..P.......250 <me@gmail.com> recipient ok

etc.

Client SMTP set to STARTTLS, it switches to encrypted after the initial handshake:

15:38:33.854310 IP relay.plus.net.587 > mobiledevice.56584: Flags [P.], seq 1:42, ack 1, win 229, length 41 E..Q..@.5..... k...w.K..m.....eVP...V...220 avasout-ptp-004 smtp relay.plus.net
...
15:38:33.942141 IP mobiledevice.56584 > relay.plus.net.587: Flags [P.], seq 1:19, ack 42, win 343, length 18 E..:..@.@......w.. k...K..eVm...P..W....EHLO [127.0.0.1]

...
15:38:33.961416 IP relay.plus.net.587 > mobiledevice.56584: Flags [P.], seq 42:208, ack 19, win 229, length 166 E.....@.5..4.. k...w.K..m.....ehP...[...250-avasout-ptp-004 hello [51.6.x.y], pleased to meet you 250-HELP
250-AUTH LOGIN PLAIN
250-SIZE 104857600
250-PIPELINING
250-8BITMIME
250-STARTTLS
250 OK

15:38:33.967510 IP mobiledevice.56584 > relay.plus.net.587: Flags [P.], seq 19:29, ack 208, win 347, length 10 E..2..@.@......w.. k...K..ehm..xP..[*...STARTTLS

15:38:33.986219 IP relay.plus.net.587 > mobiledevice.56584: Flags [P.], seq 208:232, ack 29, win 229, length 24 E..@..@.5..... k...w.K..m..x..erP.......220 Ready to start TLS

15:38:33.998208 IP mobiledevice.56584 > relay.plus.net.587: Flags [P.], seq 29:289, ack 232, win 347, length 260 E..,..@.@......w.. k...K..erm...P..[................Q........^.NDt.:.....M...0..T|. .*.....?.7W{...............$....".......+.,.../.0... .
........./.5.............
encrypted from here onwards, you cannot see the actual SMTP traffic

So it looks like STARTTLS on message submission is working fine, the traffic from the client to the plusnet submission server is encrypted.

[#6]

@seebee Thanks for that, that does show it working. I didn't rush off to get Wireshark to do something similar! I'll take it that the server is simply not reporting the connection as ESMTPSA per RFC3848.

[#7]

---

@SilverE wrote:

@bobpullen I'm looking at the connection between my PC and your server, not the onwards transmission. As I said, when I set Outlook to use STARTTLS the Received: header generated by your server (which does not give its own identity) shows ESMTPA, not ESMTPSA

---

Apologies, completely read past that aspect of your post! 😣

Looks like reassurance has since been provided though, thanks @seebee 👍