Mailing List Archive

TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received.
My campus recently switched to office365.com on port 587 from an internal Exchange server. Unfortunately, I haven't been able to connect. Typical error message is
TLS error on connection to outlook-namwest2.office365.com [40.97.133.114] (gnutls_handshake): An unexpected TLS packet was received.

Searching on the internet has some advice on setting up connections to office365, but I think I have everything set.

Could it be a problem that my passwd.client file has (some info obscured)
smtp.office365.com:xxx@ucsf.edu:xxxx
but that the ultimate host name is different, as seen above? The router uses the smtp.office365.com name.

Other ideas, including ways to isolate the problem?

I also tried with smtptest and got a similar, early, failure. It seems to be before any real authentication, since it never asked for a password. I'm putting this first because it may have more detail about the problem than the exim logs further down.
--------------------------------------------------------------------------
$ smtptest -u xxx@ucsf.edu -s -p 587 smtp.office365.com -v
starting TLS engine
setting up TLS connection
SSL_connect:before/connect initialization
write to 7FA54998CB40 [7FA54998D0C0] (517 bytes => 517 (0x205))
0000 16 03 01 02 00 01 00 01|fc 03 03 d2 00 f3 fa 76
0010 73 99 a9 80 25 a8 a9 f3|e8 7a 59 da b2 72 12 86
0020 dd 14 4a 98 f9 4e b8 e9|27 6b ac 00 00 82 c0 30
0030 c0 2c c0 28 c0 24 c0 14|c0 0a 00 a3 00 9f 00 6b
0040 00 6a 00 39 00 38 00 88|00 87 c0 32 c0 2e c0 2a
0050 c0 26 c0 0f c0 05 00 9d|00 3d 00 35 00 84 c0 2f
0060 c0 2b c0 27 c0 23 c0 13|c0 09 00 a2 00 9e 00 67
0070 00 40 00 33 00 32 00 9a|00 99 00 45 00 44 c0 31
0080 c0 2d c0 29 c0 25 c0 0e|c0 04 00 9c 00 3c 00 2f
0090 00 96 00 41 c0 11 c0 07|c0 0c c0 02 00 05 00 04
00a0 c0 12 c0 08 00 16 00 13|c0 0d c0 03 00 0a 00 ff
00b0 01 00 01 51 00 0b 00 04|03 00 01 02 00 0a 00 34
00c0 00 32 00 0e 00 0d 00 19|00 0b 00 0c 00 18 00 09
00d0 00 0a 00 16 00 17 00 08|00 06 00 07 00 14 00 15
00e0 00 04 00 05 00 12 00 13|00 01 00 02 00 03 00 0f
00f0 00 10 00 11 00 23 00 00|00 0d 00 20 00 1e 06 01
0100 06 02 06 03 05 01 05 02|05 03 04 01 04 02 04 03
0110 03 01 03 02 03 03 02 01|02 02 02 03 00 0f 00 01
0120 01 00 15 00 e0
0205 - <SPACES/NULS>

SSL_connect:SSLv2/v3 write client hello A
read from 7FA54998CB40 [7FA549992620] (7 bytes => 7 (0x7))
0000 32 32 30 20 4d 57 48
SSL_connect:error in SSLv2/v3 read server hello A -1
SSL_connect error -1
SSL session removed
failure: TLS negotiation failed!
---------------------------------------------------

This is from a debugging session with exim
---------------------------------------------------------------------------
outlook-namwest.office365.com [40.97.124.34]:587 status = usable
40.97.124.34 in serialize_hosts? no (option unset)
delivering 1d3vC1-0007Xf-NB to outlook-namwest.office365.com [40.97.124.34] (xxx@stanfordalumni.org)
set_process_info: 28999 delivering 1d3vC1-0007Xf-NB to outlook-namwest.office365.com [40.97.124.34] (xxxx@stanfordalumni.org)
Transport port=465 replaced by host-specific port=587
Connecting to outlook-namwest.office365.com [40.97.124.34]:587 ... connected
40.97.124.34 in hosts_avoid_esmtp? no (option unset)
40.97.124.34 in hosts_require_ocsp? no (option unset)
40.97.124.34 in hosts_request_ocsp? yes (matched "*")
initialising GnuTLS as a client on fd 7
GnuTLS global init required.
initialising GnuTLS client session
Expanding various TLS configuration options for session credentials.
TLS: no client certificate specified; okay
TLS: tls_verify_certificates not set or empty, ignoring
GnuTLS using default session cipher/priority "NORMAL"
Setting D-H prime minimum acceptable bits to 1024
in tls_verify_hosts? no (option unset)
in tls_try_verify_hosts? no (option unset)
TLS: server certificate verification not required.
TLS: will request OCSP stapling
about to gnutls_handshake
LOG: MAIN
TLS error on connection to outlook-namwest.office365.com [40.97.124.34] (gnutls_handshake): An unexpected TLS packet was received.
ok=0 send_quit=0 send_rset=1 continue_more=0 yield=1 first_address is not NULL
set_process_info: 28999 delivering 1d3vC1-0007Xf-NB: just tried outlook-namwest.office365.com [40.97.124.34] for xxx@stanfordalumni.org: result DEFER
added retry item for T:outlook-namwest.office365.com:40.97.124.34:587: errno=-37 more_errno=0,A flags=2

I have disable_ipv6 = true; without it exim tried only IPv6 addresses, which weren't routable by the OS.
exim 4.84_2 running on Debian Jessie.

Thanks for any help.
Ross Boylan




--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received. [ In reply to ]
I got smtptest to work, but not exim. The winning invocation was
smtptest -u xxx@ucsf.edu -a xxx@ucsf.edu -t "" -p 587 smtp.office365.com
This invocation uses -t "" rather than the previous -s, which presumably switches to TLS from SSL, and adds the -a argument to get authorization to work. Results include
subject_CN=outlook.com, issuer_CN=DigiCert Cloud Services CA-1
TLS connection established: TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)

So what is smtptest doing that exim is not? The exim debug logs sort of look as if it is expecting to negotiate TLS immediately on connection, rather than after the initial EHLO, but that seems more likely to be about what is reported rather than what happens.

Other highlights of the successful session with smtptest:
S: 220 CY1PR03CA0007.outlook.office365.com Microsoft ESMTP MAIL Service ready at Fri, 28 Apr 2017 20:46:43 +0000
C: EHLO smtptest
S: 250-CY1PR03CA0007.outlook.office365.com Hello [64.54.171.2]
S: 250-SIZE 157286400
S: 250-PIPELINING
S: 250-DSN
S: 250-ENHANCEDSTATUSCODES
S: 250-STARTTLS
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250 CHUNKING
C: STARTTLS
S: 220 2.0.0 SMTP server ready
starting TLS engine
setting up TLS connection
SSL_connect:before/connect initialization
write to 7F95E53ECB40 [7F95E53ED0C0] (517 bytes => 517 (0x205))
....
SSL_connect:SSLv2/v3 write client hello A
read from 7F95E53ECB40 [7F95E53F2620] (7 bytes => 7 (0x7))
0000 16 03 03 0d 4d 02
0007 - <SPACES/NULS>

read from 7F95E53ECB40 [7F95E53F262A] (3403 bytes => 3403 (0xD4B))
.....
# Maybe it matters that the cert is untrusted?
SSL_connect:unknown state
Peer cert verify depth=1 /C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1
verify error:num=20:unable to get local issuer certificate
verify return:1
Peer cert verify depth=1 /C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1
verify error:num=27:certificate not trusted
verify return:1
Peer cert verify depth=0 /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=outlook.com
verify return:1
...
subject_CN=outlook.com, issuer_CN=DigiCert Cloud Services CA-1
TLS connection established: TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)
Asking for capabilities again since they might have changed
C: EHLO smtptest
...
S: 250-CY1PR03CA0007.outlook.office365.com Hello [64.54.171.2]
S: 250-SIZE 157286400
S: 250-PIPELINING
S: 250-DSN
S: 250-ENHANCEDSTATUSCODES
S: 250-AUTH LOGIN
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250 CHUNKING
C: AUTH LOGIN
.....
S: 235 2.7.0 Authentication successful target host SN2PR05MB2671.namprd05.prod.outlook.com
Authenticated.
Security strength factor: 128

________________________________________
From: Boylan, Ross
Sent: Friday, April 28, 2017 11:32:41 AM
To: exim-users@exim.org
Subject: TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received.

My campus recently switched to office365.com on port 587 from an internal Exchange server. Unfortunately, I haven't been able to connect. Typical error message is
TLS error on connection to outlook-namwest2.office365.com [40.97.133.114] (gnutls_handshake): An unexpected TLS packet was received.

Searching on the internet has some advice on setting up connections to office365, but I think I have everything set.

Could it be a problem that my passwd.client file has (some info obscured)
smtp.office365.com:xxx@ucsf.edu:xxxx
but that the ultimate host name is different, as seen above? The router uses the smtp.office365.com name.

Other ideas, including ways to isolate the problem?

I also tried with smtptest and got a similar, early, failure. It seems to be before any real authentication, since it never asked for a password. I'm putting this first because it may have more detail about the problem than the exim logs further down.
--------------------------------------------------------------------------
$ smtptest -u xxx@ucsf.edu -s -p 587 smtp.office365.com -v
starting TLS engine
setting up TLS connection
SSL_connect:before/connect initialization
write to 7FA54998CB40 [7FA54998D0C0] (517 bytes => 517 (0x205))
0000 16 03 01 02 00 01 00 01|fc 03 03 d2 00 f3 fa 76
0010 73 99 a9 80 25 a8 a9 f3|e8 7a 59 da b2 72 12 86
0020 dd 14 4a 98 f9 4e b8 e9|27 6b ac 00 00 82 c0 30
0030 c0 2c c0 28 c0 24 c0 14|c0 0a 00 a3 00 9f 00 6b
0040 00 6a 00 39 00 38 00 88|00 87 c0 32 c0 2e c0 2a
0050 c0 26 c0 0f c0 05 00 9d|00 3d 00 35 00 84 c0 2f
0060 c0 2b c0 27 c0 23 c0 13|c0 09 00 a2 00 9e 00 67
0070 00 40 00 33 00 32 00 9a|00 99 00 45 00 44 c0 31
0080 c0 2d c0 29 c0 25 c0 0e|c0 04 00 9c 00 3c 00 2f
0090 00 96 00 41 c0 11 c0 07|c0 0c c0 02 00 05 00 04
00a0 c0 12 c0 08 00 16 00 13|c0 0d c0 03 00 0a 00 ff
00b0 01 00 01 51 00 0b 00 04|03 00 01 02 00 0a 00 34
00c0 00 32 00 0e 00 0d 00 19|00 0b 00 0c 00 18 00 09
00d0 00 0a 00 16 00 17 00 08|00 06 00 07 00 14 00 15
00e0 00 04 00 05 00 12 00 13|00 01 00 02 00 03 00 0f
00f0 00 10 00 11 00 23 00 00|00 0d 00 20 00 1e 06 01
0100 06 02 06 03 05 01 05 02|05 03 04 01 04 02 04 03
0110 03 01 03 02 03 03 02 01|02 02 02 03 00 0f 00 01
0120 01 00 15 00 e0
0205 - <SPACES/NULS>

SSL_connect:SSLv2/v3 write client hello A
read from 7FA54998CB40 [7FA549992620] (7 bytes => 7 (0x7))
0000 32 32 30 20 4d 57 48
SSL_connect:error in SSLv2/v3 read server hello A -1
SSL_connect error -1
SSL session removed
failure: TLS negotiation failed!
---------------------------------------------------

This is from a debugging session with exim
---------------------------------------------------------------------------
outlook-namwest.office365.com [40.97.124.34]:587 status = usable
40.97.124.34 in serialize_hosts? no (option unset)
delivering 1d3vC1-0007Xf-NB to outlook-namwest.office365.com [40.97.124.34] (xxx@stanfordalumni.org)
set_process_info: 28999 delivering 1d3vC1-0007Xf-NB to outlook-namwest.office365.com [40.97.124.34] (xxxx@stanfordalumni.org)
Transport port=465 replaced by host-specific port=587
Connecting to outlook-namwest.office365.com [40.97.124.34]:587 ... connected
40.97.124.34 in hosts_avoid_esmtp? no (option unset)
40.97.124.34 in hosts_require_ocsp? no (option unset)
40.97.124.34 in hosts_request_ocsp? yes (matched "*")
initialising GnuTLS as a client on fd 7
GnuTLS global init required.
initialising GnuTLS client session
Expanding various TLS configuration options for session credentials.
TLS: no client certificate specified; okay
TLS: tls_verify_certificates not set or empty, ignoring
GnuTLS using default session cipher/priority "NORMAL"
Setting D-H prime minimum acceptable bits to 1024
in tls_verify_hosts? no (option unset)
in tls_try_verify_hosts? no (option unset)
TLS: server certificate verification not required.
TLS: will request OCSP stapling
about to gnutls_handshake
LOG: MAIN
TLS error on connection to outlook-namwest.office365.com [40.97.124.34] (gnutls_handshake): An unexpected TLS packet was received.
ok=0 send_quit=0 send_rset=1 continue_more=0 yield=1 first_address is not NULL
set_process_info: 28999 delivering 1d3vC1-0007Xf-NB: just tried outlook-namwest.office365.com [40.97.124.34] for xxx@stanfordalumni.org: result DEFER
added retry item for T:outlook-namwest.office365.com:40.97.124.34:587: errno=-37 more_errno=0,A flags=2

I have disable_ipv6 = true; without it exim tried only IPv6 addresses, which weren't routable by the OS.
exim 4.84_2 running on Debian Jessie.

Thanks for any help.
Ross Boylan




--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received. [ In reply to ]
> The exim debug logs sort of look as if it is expecting to negotiate TLS
> immediately on connection, rather than after the initial EHLO

Yes. Look where the 465 came from:

> Transport port=465 replaced by host-specific port=587

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received. [ In reply to ]
I know I'm connecting to port 587 since I specified it explicitly. But I don't understand the relevance to my problem.

Are you saying that when exim communicates with 587 it expects to negotiate TLS immediately?
From experiments with telnet it seems clear the server does a regular greeting and then expects EHLO and STARTTLS. This seems consistent with the relevant RFC (6409 seems the most current).

Or perhaps you are saying that my use of 587 was only partly effective?

Ross
________________________________________
From: Exim-users <exim-users-bounces+ross.boylan=ucsf.edu@exim.org> on behalf of Lena--- via Exim-users <exim-users@exim.org>
Sent: Saturday, April 29, 2017 4:32 AM
To: exim-users@exim.org
Subject: Re: [exim] TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received.

> The exim debug logs sort of look as if it is expecting to negotiate TLS
> immediately on connection, rather than after the initial EHLO

Yes. Look where the 465 came from:

> Transport port=465 replaced by host-specific port=587

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received. [ In reply to ]
> I know I'm connecting to port 587 since I specified it explicitly. But I don't understand the relevance to my problem.

Exim took the port number 465 from somewhere in its config.
465 is the TLS-on-connect port.
In some other part of config you specified 587, but Exim nevertheless
tries TLS-on-connect.
Search for "465", post relevant parts of your config.
Better entire config.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received. [ In reply to ]
Thank you! The problem was that the transport had protocol = smtps. I changed it to smtp, and now it works.

The transport was
remote_smtp_smarthost:
debug_print = "T: remote_smtp_smarthost for $local_part@$domain"
driver = smtp
protocol = smtps
headers_rewrite = +rb_ucsf xxx@ucsf.edu h
return_path = xxx@ucsf.edu
hosts_try_auth = <; ${if exists{CONFDIR/passwd.client} \
{\
${lookup{$host}nwildlsearch{CONFDIR/passwd.client}{$host_address}}\
}\
{} \
}

I would like to check my understanding of what $host means in this context, as well as in the context of the authenticators which include the following code:

PASSWDLINE=${sg{\
${lookup{$host}nwildlsearch{CONFDIR/passwd.client}{$value}fail}\
}\
{\\N[\\^]\\N}\
{^^}\
}

The router uses smtp.office365.com, but this ends up resolving to different hosts, all of which seem to be called outlook-namwest.office365.com at the moment.

I think for the transport $host will be outlook-namwest.office365.com, and for authenticators the same. Is that right?

Is there an easy way for the transport and authenticator to access the original host name used by the router?

Finally, is there a way to get what the configuration is *after* all the macro processing? It has a lot of .ifdefs in it.

________________________________________
From: Exim-users <exim-users-bounces+ross.boylan=ucsf.edu@exim.org> on behalf of Lena--- via Exim-users <exim-users@exim.org>
Sent: Saturday, April 29, 2017 11:10:15 AM
To: Boylan, Ross
Cc: exim-users@exim.org
Subject: Re: [exim] TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received.

> I know I'm connecting to port 587 since I specified it explicitly. But I don't understand the relevance to my problem.

Exim took the port number 465 from somewhere in its config.
465 is the TLS-on-connect port.
In some other part of config you specified 587, but Exim nevertheless
tries TLS-on-connect.
Search for "465", post relevant parts of your config.
Better entire config.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received. [ In reply to ]
Hello!

On Sat, 29 Apr 2017 at 20:11:12 (+0000), Boylan, Ross wrote:

> The router uses smtp.office365.com, but this ends up resolving to different hosts, all of which seem to be called outlook-namwest.office365.com at the moment.

Seems to be GEO based:
[--- cut ---]
$> host smtp.office365.com
smtp.office365.com is an alias for smtp.outlook.office365.com.
smtp.outlook.office365.com is an alias for outlook.office365.com.
outlook.office365.com is an alias for lb.geo.office365.com.
lb.geo.office365.com is an alias for outlook.office365.com.g.office365.com.
outlook.office365.com.g.office365.com is an alias for outlook-emeaeast3.office365.com.
[...]
[--- cut ---]

--
George L. Yermulnik
[YZ-RIPE]

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received. [ In reply to ]
On 29/04/17 21:11, Boylan, Ross wrote:
> remote_smtp_smarthost:

> I would like to check my understanding of what $host means in this context, as well as in the context of the authenticators

It'll be whatever the MX and A, and any CNAME, DNS lookups ended up
with.

> Is there an easy way for the transport and authenticator to access the original host name used by the router?

Original? The lookup sequence starts with $domain (not a host name at
all). Is that what you're looking for?

> Finally, is there a way to get what the configuration is *after* all the macro processing?

No. An RFE wouldn't be unreasonable (if implemented it would need to be
restricted to admins though).

You can view single macro values (as an admin)
using "exim -bP macro <MACRONAME>".
_______________________________________
> From: Exim-users <exim-users-bounces+ross.boylan=ucsf.edu@exim.org> on behalf of Lena--- via Exim-users <exim-users@exim.org>
> Sent: Saturday, April 29, 2017 11:10:15 AM
> To: Boylan, Ross

Finally, please edit your responses.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received. [ In reply to ]
I think the domain refers to the ultimate destination of the message, and so it is not what I want.
More specifically, my router has
smarthost:
debug_print = "R: smarthost for $local_part@$domain"
driver = manualroute
domains = ! +local_domains
senders = +rb_ucsf
transport = remote_smtp_smarthost
route_list = * DCsmarthost byname
# RB adds next line to avoid trying IPv6 addresses, which are unrouteable
ignore_target_hosts = <; 0::0/0
host_find_failed = ignore
same_domain_copy_routing = yes
no_more
and it's the value of DCsmarthost (a macro) that I want when I'm in the transport or the authenticator, rather than the name it resolves to after all the lookups. It seems a much more natural value to use in passwd.client.

What's the procedure for an RFE?

Ross

P.S. Sorry, Outlook on the web kind of forces top-posting.
________________________________________
From: Exim-users <exim-users-bounces+ross.boylan=ucsf.edu@exim.org> on behalf of Jeremy Harris <jgh@wizmail.org>
Sent: Sunday, April 30, 2017 3:36 AM
To: exim users
Subject: Re: [exim] TLS error on connection to smtp.office365.com (gnutls_handshake): An unexpected TLS packet was received.

On 29/04/17 21:11, Boylan, Ross wrote:
> remote_smtp_smarthost:

> I would like to check my understanding of what $host means in this context, as well as in the context of the authenticators

It'll be whatever the MX and A, and any CNAME, DNS lookups ended up
with.

> Is there an easy way for the transport and authenticator to access the original host name used by the router?

Original? The lookup sequence starts with $domain (not a host name at
all). Is that what you're looking for


> Finally, is there a way to get what the configuration is *after* all the macro processing?

No. An RFE wouldn't be unreasonable (if implemented it would need to be
restricted to admins though).

You can view single macro values (as an admin)
using "exim -bP macro <MACRONAME>".

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/