5

My company has set recently set up an Active Directory driven Microsoft Exchange environment to consolidate outgoing mails. We do have a set of staging servers which should now use our MSEXCHG as smarthost for outgoing mail.

These servers are located in the DMZ, which is why the upvoted solution in Authenticating to Exchange 2010 smarthost? is not an alternative, as we cannot allow a server in the DMZ to just send mails willy-nilly via our Exchange server.

Things we have done in MSEXCHG:

  • Add a user (stagingserver@contoso.com)

Things we have done in exim4 (8):

  • Using update-exim4.conf (8) (c.f. exim4_files (5)) we configured exim to use exchange.contoso.com:587 as a smarthost.
  • In passwd.client (exim4_files (5)) I have added the following line: exchange.contoso.com:stagingserver@activedirectory.contoso.com:secret123)

After starting exim with the configuration described above, I get the following two TLS errors in mainlog:

  • TLS error on connection to ex.contoso.com [192.168.1.8] (recv): A TLS packet with unexpected length was received.
  • TLS error on connection to ex.contoso.com [192.168.1.8] (send): The specified session has been invalidated for some reason.

Our MSEXCHG then refuses to send the mail and the following (ultimate) log entry shows up:

** kiewiet@contoso.com R=smarthost T=remote_smtp_smarthost: SMTP error from remote mail server after MAIL FROM:<root@contoso-stage.com> SIZE=1538: host ex.contoso.com [192.168.1.8]: 530 5.7.1 Client was not authenticated

Further things I have tried:

So, obligatory question: How can we get exim to use our MSEXCHG environment as smarthost?

  • Have you installed OpenSSL and tried the steps here: howtoforge.com/exim-authenticated-smarthost esp.: AUTH_CLIENT_ALLOW_NOTLS_PASSWORDS = 1 ? – Lenniey Apr 14 '15 at 14:50
  • 1
    Have you tried testing the TLS connection by hand? echo quit | openssl s_client -connect ex.contoso.com:587 -starttls smtp -crlf or for gnutls ... gnutls-cli --port 587 --starttls --verbose ex.contoso.com – Paul Haldane Apr 16 '15 at 8:31
  • Yes, manual connection testing was successful. Sorry I forgot to mention that in the original question. – Christian Kiewiet Apr 22 '15 at 6:43
1

Does your organisation operate its own certificate authority for internal servers? Perhaps you need to add the CA certificates for the Exchange server into the certificate trust store for Exim? A lot of products don't report this error very well (I don't know if Exim does or not).

Wireshark (capture first on the server with tcpdump -p -s0 -w /tmp/foo.pcap then copy to a local workstation with Wireshark) should be able to show the server certificate send from Exchange, and if the client hangs up after that, then a missing CA certificate is a common cause.

  • Certificate validation is successful; tcpdump also shows that the STARTTLS handshake is seemingly successful; the three errors in the original question remained unchanged – Christian Kiewiet Apr 22 '15 at 7:27
1

Our problem was rather specific to our setup. We have more than one Exchange Server running in parallel with a load balancer acting as AP. The LB was malconfigured which caused it to neglect to offer any authentication method bar NTLM and GSSAPI even after successful STARTTLS handshake.

In-depth testing via swaks jetmore.org (can highly recommend this tool) revealed this.

-2

Problem is due to TLS certificates. Procedure to solve:

Install openssl (if missing)

sudo apt-get install openssl

Generate self certificates

sudo /usr/share/doc/exim4-base/examples/exim-gencert

Add TLS to Main SMTP

sudo nano /etc/exim4/exim4.conf.localmacros

or choose your default .conf file

main_tls_enable='1'

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.