Exim relaying through smarthost

[Morgan Blackthorne]

I'm hitting a bit of a snag recently. We're setting up a new smarthost in our AWS environment, and I'm trying to configure exim to route through it using TLS + SMTP AUTH for some basic sanity testing. However, when I try to send mail through the smarthost (mail.gomoxie.cloud), I'm getting the following message:

2019-08-05 17:04:39 1hugPW-0001hA-6q TLS session: (gnutls_handshake): An unexpected TLS packet was received.: delivering unencrypted to H=internal-UROOTCLB02-1192531143.us-east-1.elb.amazonaws.com [10.50.32.73] (not in hosts_require_tls)

It also fails to relay because it didn't authenticate. On the smarthost, the Infrastructure guys have verified via the logs that the session did an EHLO and saw the STARTTLS option, but did not activate it and instead went for MAIL FROM/RCPT TO. I'm assuming that it is not doing the SMTP AUTH because it didn't engage TLS, but I'm not sure why that is not happening. All the docs I found when googling indicated that Exim would use STARTTLS when available and advertised in the EHLO response.

My /etc/exim4/update-exim4.conf.conf looks like:

dc_eximconfig_configtype='smarthost'
dc_other_hostnames=''
dc_local_interfaces='0.0.0.0'
dc_readhost='localhost'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets='172.17.0.0/16'
dc_smarthost='mail.gomoxie.cloud::25'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'
hosts_require_tls='mail.gomoxie.cloud : internal-UROOTCLB02-1192531143.us-east-1.elb.amazonaws.com'
hosts_try_auth='mail.gomoxie.cloud'

I've tried hosts_require_tls='*' as well, with no change. (It was originally just mail.gomoxie.cloud, and then I tried adding in the ELB as well, to no avail.) I'm at a bit of a loss here, I'm not sure what's going on. It's been a while since I've done much with exim, though, I have a feeling I'm overlooking something simple and silly.

[John Stoffel]

>>>>> "Morgan" == Morgan Blackthorne <mor...@windsofstorm.net> writes:

I'm not an exim user, I personally prefer postfix and the great
support I get on the postfix users mailing list. So take my thoughts
with a grain of salt...

Morgan> I'm hitting a bit of a snag recently. We're setting up a new
Morgan> smarthost in our AWS environment, and I'm trying to configure
Morgan> exim to route through it using TLS + SMTP AUTH for some basic
Morgan> sanity testing. However, when I try to send mail through the
Morgan> smarthost (mail.gomoxie.cloud), I'm getting the following
Morgan> message:

Morgan> 2019-08-05 17:04:39 1hugPW-0001hA-6q TLS session:
Morgan> (gnutls_handshake): An unexpected TLS packet was received.:
Morgan> delivering unencrypted to
Morgan> H=internal-UROOTCLB02-1192531143.us-east-1.elb.amazonaws.com
Morgan> [10.50.32.73] (not in hosts_require_tls)

Morgan> It also fails to relay because it didn't authenticate. On the
Morgan> smarthost, the Infrastructure guys have verified via the logs
Morgan> that the session did an EHLO and saw the STARTTLS option, but
Morgan> did not activate it and instead went for MAIL FROM/RCPT
Morgan> TO. I'm assuming that it is not doing the SMTP AUTH because it
Morgan> didn't engage TLS, but I'm not sure why that is not
Morgan> happening. All the docs I found when googling indicated that
Morgan> Exim would use STARTTLS when available and advertised in the
Morgan> EHLO response.

Morgan> My /etc/exim4/update-exim4.conf.conf looks like:

Morgan> dc_eximconfig_configtype='smarthost'
Morgan> dc_other_hostnames=''
Morgan> dc_local_interfaces='0.0.0.0'
Morgan> dc_readhost='localhost'
Morgan> dc_relay_domains=''
Morgan> dc_minimaldns='false'
Morgan> dc_relay_nets='172.17.0.0/16'


Morgan> dc_smarthost='mail.gomoxie.cloud::25'

I think this is your problem. You're trying to submit on port 25.
Have you tried using just: dc_smarthost='mail.gomoxie.cloud'

[Steve VanDevender]

John Stoffel writes:
> Morgan> dc_smarthost='mail.gomoxie.cloud::25'
>
> I think this is your problem. You're trying to submit on port 25.
> Have you tried using just: dc_smarthost='mail.gomoxie.cloud'

Using port 25 should be perfectly fine. It's specifically intended for
inter-MTA traffic like this appears to be. If port 587 is available, it
often would require both STARTTLS and SMTP AUTH since it's really
intended to be used for client submission (such as Thunderbird, Outlook,
etc.).

Have you tried making a manual connection to that mail server from your
Exim host to see if there is a problem with TLS negotiation? Here's a
typical way to do it with the "openssl" utility:

$ openssl s_client -connect mail.gomoxie.cloud:25 -starttls smtp

I suggest this because I have seen problems sending mail to some Amazon
AWS hosts after I upgraded some of my systems to Debian Buster which
comes with a newer version of OpenSSL that requires larger
Diffie-Hellman keys, which Amazon isn't currently providing. Note in
the example session below the error message "dh key too small" and that
TLS is *not* negotiated. Your Exim may be trying to negotiate TLS,
failing for a similar reason, and falling back to regular SMTP.

$ host -t mx amazonaws.com
amazonaws.com mail is handled by 10 amazon-smtp.amazon.com.
$ openssl s_client -connect amazon-smtp.amazon.com:25 -starttls smtp
CONNECTED(00000003)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = amazon-smtp.amazon.com
verify return:1
139648521589888:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2156:
---
Certificate chain
0 s:CN = amazon-smtp.amazon.com
i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
i:C = US, O = Amazon, CN = Amazon Root CA 1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHqDCCBpCgAwIBAgIQD3OM9BG4YDjHDRozpwYFUDANBgkqhkiG9w0BAQsFADBG
MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRUwEwYDVQQLEwxTZXJ2ZXIg
Q0EgMUIxDzANBgNVBAMTBkFtYXpvbjAeFw0xOTA0MTYwMDAwMDBaFw0yMDAzMjYx
MjAwMDBaMCExHzAdBgNVBAMTFmFtYXpvbi1zbXRwLmFtYXpvbi5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCoussVH0anCQ9ZRfyJ38G00Ov3q0vd
empEAQJl1khiUv8QgfTq1xUjA23rnTcIb467diE0lBi3QNxArRkg4IENprVYxeAT
5/KLLyy2a0OlP+qWzD8AN0gkvGjO8bCq+IIAyKM8RZZZRtT252WA/Uw7IhL3Tj2f
SMCx4ReoUN+SVbRXuA+7MVz11XA8Tpy5k4vClKzb2FL39fdVFFqm9hiBM2QcvxYJ
P+7Jz3iGQ3H2CyvN0Y0FNL5vRpRKxTn0bVH5NAIruJ/R/EfvjKWpM3CTSCi/Oo2f
fMz9SqUlbe6tZqaIb0NZMbHMS0J5IZZoewvNocl9jNgWNrnRkn5t9UDpAgMBAAGj
ggS1MIIEsTAfBgNVHSMEGDAWgBRZpGYGUqB7lZI8o5QHJ5Z0W/k90DAdBgNVHQ4E
FgQUL1bJaGvNFw5IDwqbSogcl/oG9zwwggJSBgNVHREEggJJMIICRYIXc210cC1m
dy0yMTAxLmFtYXpvbi5jb22CGHNtdHAtZnctMzMwMDEuYW1hem9uLmNvbYIXc210
cC1mdy00MTAxLmFtYXpvbi5jb22CF3NtdHAtZnctOTEwMS5hbWF6b24uY29tghdz
bXRwLWZ3LTkxMDIuYW1hem9uLmNvbYIXc210cC1mdy02MDAxLmFtYXpvbi5jb22C
F3NtdHAtZnctNjAwMi5hbWF6b24uY29tghhzbXRwLWZ3LTM2MDAxLmFtYXpvbi5j
b22CGHNtdHAtZnctMzYwMDIuYW1hem9uLmNvbYIXc210cC1mdy0wMTAxLmFtYXpv
bi5jb22CF3NtdHAtZnctMDEwMi5hbWF6b24uY29tghdzbXRwLWZ3LTAxMDMuYW1h
em9uLmNvbYIXc210cC1mdy05MTAzLmFtYXpvbi5jb22CF3NtdHAtZnctOTEwNC5h
bWF6b24uY29tghdzbXRwLWZ3LTcwMDEuYW1hem9uLmNvbYIXc210cC1mdy03MDAy
LmFtYXpvbi5jb22CF3NtdHAtZnctNzAwMy5hbWF6b24uY29tghdzbXRwLWZ3LTcw
MDQuYW1hem9uLmNvbYIYc210cC1mdy01MjAwMS5hbWF6b24uY29tghhzbXRwLWZ3
LTUyMDAyLmFtYXpvbi5jb22CGHNtdHAtZnctNTIwMDMuYW1hem9uLmNvbYIYc210
cC1mdy01MjAwNC5hbWF6b24uY29tghZhbWF6b24tc210cC5hbWF6b24uY29tMA4G
A1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwOwYD
VR0fBDQwMjAwoC6gLIYqaHR0cDovL2NybC5zY2ExYi5hbWF6b250cnVzdC5jb20v
c2NhMWIuY3JsMCAGA1UdIAQZMBcwCwYJYIZIAYb9bAECMAgGBmeBDAECATB1Bggr
BgEFBQcBAQRpMGcwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnNjYTFiLmFtYXpv
bnRydXN0LmNvbTA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5zY2ExYi5hbWF6b250
cnVzdC5jb20vc2NhMWIuY3J0MAwGA1UdEwEB/wQCMAAwggEEBgorBgEEAdZ5AgQC
BIH1BIHyAPAAdwC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAAAWoo
My2hAAAEAwBIMEYCIQDIuFEw8USr88BCoRk3h9ZnFdlG6RYU6d5FKo0mbxIs3QIh
ALmA8pjA4ue4oOsJXutkhhk7V9uNkakWSpb7A4gG1dQwAHUAh3W/51l8+IxDmV+9
827/Vo1HVjb/SrVgwbTq/16ggw8AAAFqKDMuxQAABAMARjBEAiApimLoWHb2RTCX
vsU5jvmirxQv6WXj4hRbWKHDuBZSxwIgBD0qb20tMZph6DphOn7qknlliqRl4Jkc
DwYkIp+MarEwDQYJKoZIhvcNAQELBQADggEBAC7PAyfMtnet7lTljZ9Bwy8I08JY
Zo6f60cQgZ+uglkS2wfiDlO7/0X7dkvkB0fz9+v++eBuVwDIgE1WKoL7HzfWi2WQ
bZDg/Yjily4aDT20XHRfyW9fJrmK49bjdcbApnqlX0nj5McAFJlkaFcNM2dFMvhP
sdox4V+7S8+wWwqWUVtZf6Flw4eip3KCM9xFlrUbQt7aPeoyou2JEU5hViiNLPoX
JedXqi/bcm/5JHVI3SfS79v/bI3cKog0Zn6gqzpCXWGHu/hizBH1MAK/8ogV/Dvi
Tg9e9o/m7xaG+CZRiV/7dyNAWs0IoS6X+mFM+3FWqg6uMvlGbU36ovdpsvo=
-----END CERTIFICATE-----
subject=CN = amazon-smtp.amazon.com

issuer=C = US, O = Amazon, OU = Server CA 1B, CN = Amazon

---
No client certificate CA names sent
---
SSL handshake has read 3809 bytes and written 354 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1565127503
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---