TLS inbound mail from outbound.protection.outlook.com ssl_err=5 and milter-greylist

[Pär Bertilsson]

I recently started to observe that I have problems with incoming mails from the *.outbound.protection.outlook.com. in combination with using filter-greylist.

When receiving inbound connections on port 25 the TLS session seems to be terminated by the outlook.com client a bit brusquely which is a puzzel to me, see below. This just seems to happen with mail from outlook.com ?!?!

It appears that the TLS is established as expected and data is going through (if whitelist the client), see SSL dump below.

The actual problem is when grey-listning is enabled the client is request to come back later and the session ends with this ssl error, the grey-listning never register the client and therefor the duration time is never being reduced in for upcoming retries.

As I see it appears to me that the root cause is the SSL termination issue (?) Any hints what that could cause that?



I have an owned signed 2048 bit certificate and is that my host name is equal with the certificate FQDN name and it has not expired

best regards,
Pär


Nov 6 16:04:21 hoddmimes sendmail[30310]: STARTTLS=server, relay=mail-eopbgr50113.outbound.protection.outlook.com [40.107.5.113], version=TLSv1.2, verify=NOT, cipher=ECDHE-RSA-AES256-SHA384, bits=256/256
Nov 6 16:04:23 hoddmimes milter-greylist: vA6F4Gk5030310: addr mail-eopbgr50113.outbound.protection.outlook.com[40.107.5.113] from <f...@xxxxxxxx.se> to <fr...@yyyyyyyy.com> delayed for 00:32:00 (ACL 242)
Nov 6 16:04:23 hoddmimes sendmail[30310]: vA6F4Gk5030310: Milter: to=<fr...@yyyyyyyy.com>, reject=451 4.7.1 Greylisting in action, please come back later
Nov 6 16:04:23 hoddmimes sendmail[30310]: STARTTLS: write error=syscall error (-1), errno=104, get_error=error:00000000:lib(0):func(0):reason(0), retry=99, ssl_err=5
Nov 6 16:04:23 hoddmimes sendmail[30310]: vA6F4Gk5030310: from=<f...@xxxxxxxxx.se>, size=1594536, class=0, nrcpts=0, proto=ESMTPS, daemon=MTA, relay=mail-eopbgr50113.outbound.protection.outlook.com [40.107.5.113]

It appears that the TLS session


New TCP connection #1: mail-oln040092071029.outbound.protection.outlook.com(29616) <-> hoddmimes.com(25)
1 1 5.2523 (5.2523) C>S Handshake
ClientHello
Version 3.3
cipher suites
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
compression methods
NULL
1 2 5.2582 (0.0059) S>C Handshake
ServerHello
Version 3.3
session_id[0]=

cipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
compressionMethod NULL
1 3 5.2582 (0.0000) S>C Handshake
Certificate
1 4 5.2582 (0.0000) S>C Handshake
ServerKeyExchange
Not enough data. Found 327 bytes (expecting 32767)
1 5 5.2582 (0.0000) S>C Handshake
ServerHelloDone
1 6 5.3149 (0.0566) C>S Handshake
ClientKeyExchange
Not enough data. Found 64 bytes (expecting 16384)
1 7 5.3149 (0.0000) C>S ChangeCipherSpec
1 8 5.3149 (0.0000) C>S Handshake
1 9 5.3156 (0.0007) S>C Handshake
1 10 5.3156 (0.0000) S>C ChangeCipherSpec
1 11 5.3156 (0.0000) S>C Handshake
1 12 5.3610 (0.0453) C>S application_data
1 13 5.3614 (0.0004) S>C application_data
1 14 5.4427 (0.0812) C>S application_data
1 15 5.9911 (0.5483) S>C application_data
1 16 6.0708 (0.0797) C>S application_data
1 17 6.0711 (0.0002) S>C application_data
1 18 6.1518 (0.0807) C>S application_data
1 19 6.1638 (0.0119) S>C application_data
1 20 6.2462 (0.0823) C>S application_data
1 6.2462 (0.0000) C>S TCP RST

[Claus Aßmann]

Pär Bertilsson wrote:

> The actual problem is when grey-listning is enabled the client is request to come back later
> and the session ends with this ssl error, the grey-listning never register the client and
> therefor the duration time is never being reduced in for upcoming retries.

Why not? Looks like a bug in the milter -- it has the client IP and
the info that it (temporarily) rejected the connection so it should
just keep track of that (i.e., as soon as it made the decision,
it shouldn't wait from some later step in the SMTP session which may
or may not happen.)

PS: ssl_err=5 = SSL_ERROR_SYSCALL -> check errno which is 104 in
your case -- ECONNRESET on a Linux box.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

[Pär Bertilsson]

I have to apologise. This is somewhat a fairly known problem with outlook shifting IP host when resending mail causing long delays.

https://www.google.se/search?source=hp&ei=2O0FWpm2G4b-6ATIxaHYAQ&q=milter+greylist+outbound.protection.outlook.com+long+delays&oq=milter+greylist+outbound.protection.outlook.com+long+delays

The somewhat brusquely TLS session termination is another thing, but that is not causing us any sever headache.

Sorry for take up space and time.
Pär