Re: [exim] Please check for SSL transport errors

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Phil Pennock
日付:  
To: The Doctor
CC: exim-users
題目: Re: [exim] Please check for SSL transport errors
On 2017-02-11 at 06:14 -0700, The Doctor wrote:
> root@gallifrey:/usr/source # exim -d -bV
> Exim version 4.89 #5 built 11-Feb-2017 05:34:07
> Probably Berkeley DB version 1.8x (native mode)



> root@gallifrey:/usr/source/exim-4.88/build-FreeBSD-amd64 # ./exim -bV -d
> Exim version 4.88 #7 built 11-Feb-2017 05:26:16
> Berkeley DB: Berkeley DB 6.2.23: (March 28, 2016)


Well that's why you're getting broken hints databases.

Build 4.89 with the same DB you built 4.88 with.

> root@gallifrey:/usr/source # sendmail -v -qff -d+all
> 05:14:37 26075 Exim version 4.89 uid=0 gid=0 pid=26075 D=fffdffff

[...]
> 05:14:37 26078 SMTP<< 220 TLS go ahead

[...]
> 05:14:38 26078 SMTP>> BDAT 90864 LAST

[...]
> 05:14:38 26078 tls_do_write(0x804022000, 8191)
> 05:14:38 26078 SSL_write(SSL, 0x804022000, 8191)
> 05:14:38 26078 outbytes=8191 error=0
> 05:14:38 26078 flushing headers buffer
> 05:14:38 26078 writing data block fd=8 size=8191 timeout=300
> 05:14:38 26078 tls_do_write(0x804022000, 8191)
> 05:14:38 26078 SSL_write(SSL, 0x804022000, 8191)
> 05:14:38 26078 outbytes=-1 error=5
> 05:14:38 26078 LOG: MAIN
> 05:14:38 26078 SSL_write: (from <unknown>) syscall: Broken pipe


So the SSL write failed, because the other side dropped the TCP
connection from under you. So the remote side barfed without a TLS
teardown.

Is the other side Exim 4.88 with its known chunking problems?

On the _remote_ side, if that's yours, then:

    # Bug-fixes 4.88
    chunking_advertise_hosts =


Much of the reason why we're releasing 4.89 so soon is that 4.88 has
some Issues.

> 05:14:38 26077 == root@??? R=dnslookup T=remote_smtp defer (32): Broken pipe H=doctor.nl2k.ab.ca [204.209.81.1]: SMTP error from remote mail server after sending data block: 250 423 byte chunk received


Looks like known problems with counting bytes in chunking. The
remote side is Exim 4.88 isn't it?

I see no signs of a TLS problem, other than that TLS is what reported
the connection being abruptly dropped from under it by the remote side.

-Phil