Ubuntu
exim4 package

  1. Bug #1974214
  2. Comment #13

Comment 13 for bug 1974214

Revision history for this message
In , Gedalya-b (gedalya-b) wrote :

Created attachment 1414
exim4-daemon-light 4.96~RC0-1

Versions: 4.94 good, 4.9[56] bad.
OS: Debian testing x86_64
TLS: gnutls 3.7.4-2, haven't tried OpenSSL

This doesn't happen in an immediate delivery attempt or in "exim -M", but in a queue runner, if the first remote server responds with a deferral, exim crashes some time when talking to the next server. It can happen in tls_close() (after the message was successfully delivered, if the remote parry allows, or after getting a deferral): smtp_deliver -> tls_close -> gnutls_certificate_free_credentials -> gnutls_x509_trust_list_deinit,

or it can be: smtp_deliver -> smtp_setup_conn -> tls_client_start -> verify_certificate -> gnutls_certificate_verify_peers2 -> gnutls_certificate_verify_peers -> _gnutls_x509_cert_verify_peers -> gnutls_x509_trust_list_verify_crt2 -> gnutls_x509_trust_list_get_issuer -> _gnutls_trust_list_get_issuer

And on one occasion it crashed in arc_sign() (on an exim thus built)

But long story short, it seems like exim would consistently crash, SIGFPE or SIGSEGV, during a subsequent delivery attempt after a deferral response.

The real life circumstances are a gmail account over quota or a forwarded message graylisted by gmail or such. But I am reproducing this by simply configuring my own exim servers to defer.

Attached is a log excerpt and backtrace from Debian's exim4-daemon-light 4.96~RC0-1